How Does Live Food-Delivery Tracking Work?

From order to moving dot

This Byte explains what happens when you track a Swiggy or Zomato order, where the customer, restaurant and rider all need to see useful, timely status updates on a moving map. No earlier Byte is required.

This is an illustrative model based on publicly available system-design patterns, not an internal disclosure from Swiggy or Zomato.

Following lunch on the map

Karthik orders lunch while debugging, and idly watches the rider's icon glide smoothly across the map. Meena asks: "How is that not jerky? My phone isn't constantly refreshing that page." Divya says this is actually a great parallel to a feature PaisaWise has discussed — showing customers a live status as their support ticket or refund request moves between stages. Rahul: "So this isn't just food-delivery trivia — it's the same shape as any live status feature."

Location updates and order states

A food delivery order involves three parties whose status has to stay consistent: the restaurant (preparing the order), the rider (picking it up and moving toward you), and your app (showing you both). The tricky part isn't showing one status — it's continuously updating one specific piece of it, the rider's live location, without your phone having to constantly ask "are we there yet?"

The common approach is to flip who initiates the update: instead of your app repeatedly asking the server "where's my rider now?" (called polling), the server pushes the rider's location to your app the moment it changes, over a connection that stays open (commonly via WebSockets). Think of the difference between refreshing a webpage every few seconds to check for news, versus subscribing to a notification that arrives the instant there's news — the second approach is both faster and far less wasteful at scale.

How an update reaches your phone

A simplified flow for how a rider's location reaches your screen:

1. Rider's phone sends GPS coordinates every 2-3 seconds while moving
2. Coordinates go to the backend (not the main order database directly,
3. but a fast, temporary store built for exactly this kind of data)
4. Your app holds an open connection to the server for this specific order
5. The moment new coordinates arrive, the server pushes them to your app
6. Your app moves the rider's icon smoothly on the map (small in-between
7. steps are animated, so it looks like continuous motion, not jumps)

Why a temporary, fast store instead of the main database:

1. Every rider's location changes every few seconds
2. Writing every update into the main order database would overload it
3. Instead, live location goes into a fast, temporary store (commonly Redis)
4. Old location data automatically expires — it's only useful for a few
5. seconds anyway
6. The main database still holds the order's actual state
7. (preparing / picked up / delivered)

Decide what the app should show

A design exercise, instead of a code snippet:

Sketch, in the same style as the earlier section, what you think should happen if the rider's phone loses network connectivity for two minutes mid-delivery. What should your app show during those two minutes — the last known location, nothing, or something else? What should happen the moment their connection comes back?

Tracking at busy-hour scale

Publicly available engineering write-ups on real-time delivery tracking describe rider location updates as small payloads sent every few seconds while moving. A fast in-memory store can serve the latest position while old entries expire automatically because they are useful only briefly. The customer-facing map can animate the marker between updates through interpolation, creating smooth movement instead of visible jumps. Treat these as common illustrative engineering patterns rather than a confirmed disclosure of any specific company's exact system.

When the dot is late or wrong

1. Assuming your app is constantly asking the server for updates — as the earlier section covers, the more common and efficient pattern is the server pushing updates the moment they happen, not your app repeatedly polling.
2. Assuming rider location is stored the same way as order history — as shown in the earlier section, live, rapidly-changing location data is typically handled by a separate, fast, temporary store, distinct from the durable database holding the order's actual state.
3. Expecting the map marker to jump exactly in sync with the rider's real position — what you see is often a smoothed, interpolated animation between the last two known points, not a live camera feed of their exact location.
4. Not planning for a connectivity gap — as the earlier section asks, a rider losing signal briefly is a normal case that a tracking feature needs to handle gracefully, not an edge case to ignore.

How teams use tracking signals

For frontend and backend engineers, the design decision is to separate durable order state from temporary live location. Product and support teams must also define what the customer sees when updates become stale. The same pattern works for shipments, service appointments, field staff and live support queues.

What customers see and systems know

Sketch a tracking experience

Sketch (in the earlier section's style) what you think happens when a rider is assigned a second delivery on the way to your address — a batched order. What additional status or piece of information would your app need to show that it didn't need before?

What to remember

• A food delivery order involves three parties — restaurant, rider and customer app — whose statuses need to stay in sync.
• Push (server-initiated updates) is generally more efficient than polling (the app repeatedly asking) for anything that changes frequently and unpredictably.
• Rapidly-changing data like live location is typically handled by a fast, temporary store, separate from the durable database holding the order's actual state.
• What looks like smooth, continuous motion on a map is often an animated interpolation between periodic real updates, not a live feed of exact position.
• This byte is presented as an illustrative model based on public write-ups, not a confirmed disclosure of any specific company's system.
• A stale-location indicator is safer than pretending an old coordinate is current.
• Reconnection logic should restore the latest useful state without replaying every obsolete coordinate.
• The next learning step is to design how the map behaves during a short network gap.

Questions learners ask

Q1: Does your app typically ask the server "where's my rider?" every few seconds? Not in this model — the more common pattern is the server pushing location updates to your app the moment they change, rather than the app repeatedly asking.

Q2: Is a rider's live location typically stored in the same database as the order's history? No — live location is typically handled by a separate, fast, temporary store, since it changes far more frequently than the durable order record needs to.

Q3: Does the rider's icon on the map move exactly in real time with their actual position? Not exactly — it's commonly a smoothed, animated interpolation between the last known update points, rather than a continuous live feed.

Check your understanding

Primary sources

• MDN WebSocket API — persistent two-way browser and server communication.
• Public food-delivery system-design studies — real-time location, temporary state and map interpolation patterns.

Next byte: What Happens When Netflix Plays a Video Without Constant Buffering — a different kind of problem: smoothness under changing network conditions, not multi-party synchronization.