Design a Location-Based "Proximity Chat"

Problem Statement

Design a location-based proximity chat platform where users automatically discover, join, and participate in chat rooms scoped to a physical area. A user attending a concert, conference, sports game, or walking through a neighborhood sees a chat populated exclusively by other users within a configurable radius or geofenced boundary. When the user moves outside the boundary, they lose write access or leave entirely. Rooms may be ephemeral—created for a time-boxed event and dissolved afterward.

This is not a traditional persistent chat system. WhatsApp, Telegram, and Discord optimize for durable conversations between known contacts. Proximity chat inverts every assumption: membership is transient, rooms are spatially bounded, anonymity may be the default, and the primary index is not a conversation ID but a geographic cell with a time window.

Why the problem is distinctive

A persistent chat backend stores messages indefinitely, indexes by conversation, and replicates to all members regardless of location. Proximity chat demands:

1. Spatial indexing at write time — every position update must determine room membership in real time.
2. Ephemeral membership — a user's subscription to a room is a lease that expires when they leave the geofence.
3. High-churn fan-out — at a 50,000-person concert, users enter and exit rooms at rates of hundreds per second.
4. Location integrity — the system must resist GPS spoofing, since the location itself is the access control token.
5. Moderation without identity — anonymity makes abuse harder to attribute and deter.

The four architectural planes

1. Geospatial plane: continuous position ingestion, cell-based indexing (H3, S2, or geohash), geofence evaluation, and membership derivation.
2. Messaging plane: real-time message delivery via WebSocket, fan-out to room members, presence, typing indicators, and message history with bounded retention.
3. Lifecycle plane: room creation, geofence definition, time-boxed expiry, capacity limits, and dissolution.
4. Trust plane: location verification, anti-spoofing, moderation pipeline, rate limiting, and abuse detection.

A strong design keeps these planes separate. The geospatial plane may degrade to coarser granularity without breaking message delivery. The messaging plane may buffer during brief connectivity gaps without corrupting membership. The lifecycle plane operates asynchronously without blocking real-time chat.

Public operating baseline

Yik Yak (2013–2017, relaunched 2021) demonstrated hyperlocal anonymous messaging at scale, peaking at over 5 million monthly active users with a 5-mile radius feed. Discord reports over 200 million monthly active users (2023) and sustains millions of concurrent WebSocket connections per shard. Niantic's Pokémon GO processes location updates from hundreds of millions of players using S2 cell-based spatial partitioning. Telegram's "People Nearby" feature exposes location-proximity discovery to 900M+ users.

For capacity planning, this answer explicitly assumes a mature platform with 2 million DAU, 400,000 peak concurrent users, 50,000 concurrent users in a single large event, and a 5× burst multiplier. Unless tied to a citation, every number is a stated design assumption.

Core engineering tension

The fundamental tension is freshness versus cost. Every user position update potentially changes room membership, triggering join/leave events, fan-out recalculations, and presence broadcasts. At 400K concurrent users updating every 5 seconds, that is 80,000 position updates per second. Naively re-evaluating every geofence for every update is O(users × geofences). The design must reduce this to O(1) or O(log N) per update using spatial hashing.