Swiggy Shows Wrong Rider Location: System Design Deep Dive on Real-Time GPS Tracking and Eventual Consistency

System Design Real Scenarios — A Popular Interview Question That Tests Real-Time Streaming, WebSockets, GPS Polling, and Geo-Distributed Systems

This is the kind of system design question that separates engineers who have thought about real-time systems from those who have not.

The problem sounds simple: the app shows the delivery partner at the wrong location. But behind this single symptom lies a chain of systems that must work together perfectly — GPS hardware, mobile battery optimization, network latency, server-side state management, real-time push infrastructure, and database replication across geographic regions.

Interviewers love this question because it starts with a visible user experience problem and gradually uncovers whether you understand:

• How GPS polling works and why frequency is a tradeoff between accuracy and battery life
• Why HTTP polling falls apart for real-time updates and where WebSockets step in
• How eventual consistency creates confusing UX in location-aware systems
• The challenges of geo-distributed databases when location data must be read and written across regions

In the previous episode, we explored how messaging platforms handle duplicate deliveries. Today, we step into the world of real-time location tracking.

Let’s watch how the conversation unfolds.

Full story for non-members | Instagram-@arvind.codefarm | E-Books on Java/Microservices/Springboot | Whatsapp Group

The Scenario

Arvind (Interviewer): A customer orders food on Swiggy. The app shows the delivery partner is outside the customer’s house. The customer steps out. Nobody is there. The rider is still 3 kilometers away.

How would you debug this? And more importantly, how would you redesign the system so location updates are accurate?

Priya (Candidate): Let me start by mapping how location tracking works in a food delivery app.

The rider’s phone captures GPS coordinates at certain intervals and sends them to the server. The server stores the latest location and pushes it to the customer’s app.

The customer sees whatever location was last pushed to their app. If that location is stale, the map shows a position the rider was at minutes ago — not where they are now.

Arvind: Good. So what causes the location to be stale?

Priya: There are three failure points.

First, the GPS polling interval. The rider app does not send location continuously because that drains the battery. If the app polls every 30 seconds, the location shown on the customer’s phone is up to 30 seconds old — or older when network and server delays stack up.

Second, network failures. The rider enters a tunnel or a weak signal zone. The location update never reaches the server. The server keeps serving the last known good location.

Third, the server to customer push is delayed. Even if the server gets a fresh location, pushing it to the customer’s phone takes time. If the push channel uses HTTP polling, the customer might not see the update for several seconds or minutes.

Arvind: You mentioned HTTP polling. How do real-time delivery apps solve the push problem?

Priya: Most modern systems use WebSockets instead of HTTP polling.

WebSocket keeps a persistent TCP connection open between the customer’s app and the server. When the rider’s location changes, the server pushes the update immediately through this open channel. No polling. No delay.

But WebSockets alone do not solve the GPS polling problem on the rider side. The rider’s app still decides how often to capture coordinates.

Arvind: So how do you decide the right GPS polling frequency?

Priya: It is adaptive. Fixed intervals are the wrong approach because context changes.

If the rider is moving fast on a bike, poll more frequently because location changes rapidly. If the rider is stationary at a restaurant waiting for the order, poll less frequently to save battery. If the rider is within 500 meters of the destination, increase polling frequency for accurate arrival estimates.

This is called adaptive polling. Combined with significant-change detection — only send an update when the location has changed by more than X meters — you get accuracy where it matters and battery savings where it does not.

Arvind: Now imagine Swiggy operates across India. A rider in Bangalore delivers food. The customer is in Bangalore too. But the server handling the customer’s request is in Mumbai. Does geography matter here?

Priya: It matters enormously.

In a geo-distributed system, the rider’s location is written to the nearest data center. That data then needs to replicate to the data center serving the customer. Replication takes time — hundreds of milliseconds to seconds.

If the customer’s WebSocket server reads from a local replica that has not received the latest location yet, the customer sees stale data.

The solution is a combination:

• Write to local region: Rider’s location goes to the nearest ingestion endpoint
• Read your own writes: The customer’s connection is routed to the same region as the rider when possible
• Edge caches with TTL: Frequently read rider locations are cached at edge locations with a seconds-long TTL
• Geohash-based partitioning: Rider locations are stored and retrieved using geohashes so reads are localized to nearby servers

Arvind: Let us talk about eventual consistency specifically. The customer sees a stale location because the replica has not caught up. How do you handle this without making the system strongly consistent (which would be slow)?

Priya: This is exactly where eventual consistency hurts location-based systems. Strong consistency would require every location write to be confirmed by all replicas before the customer can read it — which adds latency and reduces availability.

The pragmatic approach is:

1. Session affinity: Route the rider and the customer to the same regional data center. The write and read happen on the same node. No replication lag.
2. Versioned locations: Every location update carries a timestamp. The customer app checks: “Is this newer than what I have?” If a delayed update arrives out of order, the app ignores it.
3. Interpolation: The customer app predicts the rider’s position between updates using the last known speed and direction. Even if the location is a few seconds stale, the estimated position is close to reality.
4. Client-side staleness indicator: If the app has not received an update in more than 30 seconds, show a “Location may be inaccurate” warning instead of a confidently wrong dot on the map.

Arvind: That interpolation idea is interesting. Walk me through how it works.

Priya: Imagine the rider sends location at T=0 and T=10 seconds. At T=5, the customer has no update. But the app can calculate: at T=0 the rider was at point A, heading east at 30 km/h. Five seconds later, the rider should be approximately 40 meters east of point A.

The customer app shows an estimated position between updates. When the next real location arrives, the estimate is corrected. If the estimate was close, the rider’s icon moves smoothly. If it was off, the icon snaps to the real location.

This is how platforms like Uber, Swighi, and Zomato make the rider’s icon appear to move smoothly rather than jumping every few seconds.

Arvind: Let us design the complete architecture. What would your system look like?

Priya:

Key decisions:

• Adaptive polling on rider app: Battery-efficient. Frequency changes based on speed, distance to destination, and movement pattern.
• Kafka for ingestion: Decouples the write path (rider sending location) from the read path (customer viewing location). Burst tolerance.
• Redis for latest location: Each rider’s most recent location is stored in Redis with a short TTL. Millions of reads per second without hitting the database.
• Cassandra for history: Time-series location data for analytics, route replays, and dispute resolution.
• WebSocket for real-time push: Persistent connection to every customer viewing an active order. Server pushes location deltas.
• Interpolation on client: Smooth movement between updates. Fallback when updates are delayed.

Arvind: What monitoring would tell you the system is healthy?

Priya: I would track:

1. Location staleness per rider — Time since the last location update was received. If it exceeds 30 seconds for more than 1% of active riders, investigate.
2. WebSocket message latency — P95 time between server receiving a location and pushing it to the customer.
3. GPS polling success rate — Percentage of scheduled polls that successfully capture a location.
4. Interpolation error distance — How far off the estimated position was when the next real location arrived. Large errors indicate polling is too infrequent.
5. Replica lag — Time difference between primary write and replica read for location data.
6. Consumer location accuracy score — Compare estimated position vs actual position at delivery time.

Let’s Conclude

The Swiggy wrong rider location problem is not about fixing a single bug. It is about understanding that real-time location tracking is a chain of systems, and the chain is only as strong as its weakest link:

• GPS hardware decides precision
• Polling frequency decides freshness
• Network decides whether data reaches the server
• WebSockets decide how fast data reaches the customer
• Database replication decides whether the customer sees current data
• Client-side interpolation decides whether the experience feels smooth

The winning architecture combines adaptive GPS polling, Kafka-based ingestion, Redis for hot-path reads, WebSocket push, and client-side interpolation — layered with monitoring that catches staleness before users notice it.

Key takeaways:

• Rider side: Adaptive polling + significant-change detection
• Server side: Kafka ingestion + Redis latest-location cache + WebSocket push
• Customer side: Client-side interpolation + staleness detection + versioned updates
• Geo-distribution: Session affinity to same region + edge caches with short TTL

That is how platforms like Swiggy, Uber, and Zomato keep millions of users watching moving icons in real time.

Liked this deep dive story? If Yes Please 👏 Clap(50) | 📤 Share | 🔔 Follow

Below is a collection of all related stories in one place

[embed]List: 22 Scenarios for System Design Interview | Curated by Arvind Kumar | Medium 22 Scenarios for System Design Interview · System Design Real Scenarios Series - Conversation between two people - easy…medium.com