News · New this week
Live rider tracking on a map: a system design walkthrough
GPS pings, Redis pub-sub plus a last-position key, and WebSocket push. A common system design answer, broken down piece by piece.
If an interviewer asks how you'd show a rider live on a map, the answer is a short pipeline. The rider app pings GPS, a stateless API publishes it, Redis holds it, and socket servers push it to the customer. Each piece exists for a reason, so here's the reasoning.
Start with the rider app
The rider app sends a GPS ping every four seconds. That interval is a trade. Ping faster and you drain the rider's battery. Ping slower and the marker teleports across the map instead of moving.
Keep the ingest API stateless
Take one lakh riders, so 100,000, each pinging every four seconds. That's 25,000 requests a second.
The ingest API sits behind a load balancer and keeps no state. Any server can take any ping, so when load grows you add servers and they absorb it. Stateless servers scale out.
Redis does two jobs
The API publishes each ping on the order's channel in Redis. That alone isn't enough. Pub-sub keeps no history, and subscribers only get messages sent while they're connected.
So the API also sets the latest position under a key. The pub-sub channel carries live updates. The key holds the last known spot. You need both.
Socket servers push to the customer
Socket servers hold open WebSockets to customer apps. When a customer connects, the server verifies their token, then subscribes to that order's channel. Each new position arrives from Redis and goes straight down the socket. The customer app animates the marker to the new spot.
What happens when signal drops
Phones lose signal. When that happens, the marker holds its last spot instead of vanishing or jumping.
On reconnect, the server reads the saved key first and sends that position before anything else. Think of a scoreboard. Nobody needs every play they missed, they need the latest score. The same applies here, the customer only cares where the rider is now.
The whole flow in one line
Ping every four seconds, publish per order, keep the last spot, push over WebSockets.
Next time you sketch this on a whiteboard, say the numbers out loud: four seconds, 25,000 requests a second. Then explain why the key sits next to the pub-sub channel. That's the detail that shows you've thought about disconnects. And try answering the follow-up the reel ends on: would you pick WebSockets, SSE or polling here, and why?
