EASYwalkthrough
Real-Time Location Tracking
Once we match a rider and driver, both need to see each other's location moving on the map in near real time. The constraint: polling every second wastes bandwidth and battery, and HTTP long polling adds connection overhead for high-frequency updates.
Trade-off: we accepted the operational complexity of stateful connections in exchange for 99% lower request volume (1 connection vs 300 polls per ride). Each update is a lightweight payload: driver_id (8B) + lat (8B) + lng (8B) + heading (4B) + speed (4B) + timestamp (8B) = 40 bytes.
“We chose WebSocket connections for active ride tracking (not HTTP polling) because WebSocket pushes updates server-to-client without per-request overhead.”
At peak with 100K concurrent active rides, that is 100K WebSocket connections pushing 40 bytes every 3 seconds = 1.3 MB/sec total egress, trivial for modern load balancers. The WebSocket server is stateful (each connection is pinned to a server), so we use connection-aware routing: a service registry maps ride_id to WebSocket server ID.
If a WebSocket server fails, the client reconnects and the registry re-routes to a healthy server. The reconnection gap is typically under 2 seconds.
For the pre-match phase (rider sees nearby drivers on the map), we use HTTP polling every 5 seconds since the update frequency is lower and there is no persistent relationship to maintain.
Related concepts