Predictive Systems
Swiggy Delivery Time Prediction
How cooking time, rider supply and traffic combine into one promise made before the restaurant has even accepted the order.
How cooking time, rider supply and traffic combine into one promise made before the restaurant has even accepted the order.
Before you have paid, the app promises a delivery time. At that moment the restaurant has not accepted the order, no rider has been assigned, and nobody has started cooking. The number is a forecast about a chain of events that has not begun.
It is a harder problem than route ETA, because road travel is only one of three components. A dish that takes twenty-five minutes to prepare dominates a six-minute ride, and kitchen speed varies with how busy the restaurant already is.
There is also a business asymmetry that shapes the whole design. Arriving early is a pleasant surprise; arriving late is a complaint, a refund and sometimes a lost customer. The system is not trying to be accurate — it is trying to be reliably not-late.
Think of it like this: it is like promising when a dinner party will be served, before you have checked whether the oven is free, whether anyone is available to fetch the ingredients, or how bad the traffic is on the way back.
The estimate has to survive several sources of variability that compound on one another:
The same dish takes wildly different times depending on how many orders the restaurant is already handling.
During peak hours no rider may be free, adding a wait before the journey even begins.
One rider often carries several orders, so your food may wait while another customer is served first.
Three uncertain legs in sequence produce far more spread than any single one of them.
Being ten minutes early costs almost nothing. Being ten minutes late costs a refund and trust.
Rather than predicting one number, the system predicts each leg of the journey separately and composes them, because each leg has entirely different drivers and its own data.
Predicts food preparation time from the specific dishes ordered, the restaurant's historical speed and how many orders it currently has in progress.
In shortWorks out how long the cooking will take, given how busy the kitchen already is.
Tracks how many riders are free, busy or approaching availability in the area around the restaurant right now.
In shortKeeps a live count of who is available to carry your order.
Estimates how long until a rider will actually be assigned and reach the restaurant, which during peak hours can exceed the cooking time.
In shortGuesses how long before someone is free to come and collect it.
Predicts rider travel time for both the leg to the restaurant and the leg to the customer, using road conditions and two-wheeler routing.
In shortEstimates the riding time, there and then onward to you.
Decides whether to group nearby orders onto one rider, which improves efficiency but adds detour time to some deliveries.
In shortDecides whether your order shares a rider with someone else's.
Converts the internal prediction into the number shown to the customer, adding buffer calibrated to how confident the model is.
In shortTurns the honest guess into a safer promise before showing it to you.
Even before an order exists, a rough estimate is shown per restaurant using its typical preparation time and current area conditions.
In shortThe time on the listing page is already a prediction, made before you have chosen anything.
Once the basket is known, the specific dishes and their preparation profiles sharpen the kitchen estimate.
In shortOnce it knows what you ordered, the guess gets more specific.
Kitchen time, rider assignment delay, travel to restaurant and travel to customer are each predicted independently.
In shortEvery stage of the journey gets its own estimate.
The legs are combined and a buffer is added, sized according to the uncertainty of this particular order and area.
In shortThe parts are added up and a safety margin is put on top.
When a rider is actually assigned, the assignment uncertainty collapses into a known value and the estimate is revised.
In shortOnce a real rider takes the job, one of the guesses becomes a fact.
Pickup confirmation and live rider location progressively replace prediction with observation until delivery.
In shortAs it actually happens, guessing gives way to watching.
A single model predicting total delivery time performs poorly, because the legs are driven by unrelated factors and fail in different ways.
Driven by dish complexity, restaurant throughput and current kitchen load. A busy kitchen does not cook one dish slower — it queues, so the marginal order waits behind everything already in progress.
In shortCooking time depends less on the dish and more on how long the queue in front of it is.
Depends entirely on rider supply relative to demand in that area, and is close to zero off-peak while becoming the dominant term during a dinner rush.
In shortAt quiet times a rider is instant; at peak times waiting for one can be the longest part.
The rider's journey to the restaurant, which can overlap with cooking if assignment happens early enough — good dispatch hides this leg entirely.
In shortThe ride to the restaurant, which ideally happens while the food is still cooking.
Restaurant to customer, plus the frequently underestimated final stretch: parking, finding the building, lifts and gates.
In shortThe ride to you, including the surprisingly slow business of actually reaching your door.
The intuitive method is to add the restaurant's average preparation time to the travel time. It produces an estimate that is right on average and wrong exactly when it matters:
In short: the system does not predict a single number, it predicts a distribution and then deliberately quotes a pessimistic point within it. It would rather be six minutes early most of the time than be accurate on average and late half the time.
Assigning one order per rider is simplest and least efficient. Batching improves economics but directly trades against individual delivery time.
Two orders on similar routes can share a rider, roughly halving the delivery cost per order and easing supply pressure during peaks.
In shortOne rider carrying two orders costs about half as much per order.
The second order in a batch waits while the first is delivered, so its delivery time increases even though the system as a whole is more efficient.
In shortIf yours is the second drop, you wait longer so that the fleet works better overall.
Orders are only batched when pickup points and drop-offs are genuinely close and the added delay stays within an acceptable bound.
In shortIt only pairs orders when the detour is small enough not to hurt.
Because batching happens after the promise is made, the estimate must account for the probability of being batched, not just the current plan.
In shortThe promise has to allow for the chance that your order ends up sharing a ride.
Estimates are requested constantly — every listing page shows dozens — so the cost per prediction has to be very low:
| Layer | Common Choices |
|---|---|
| Order Events | Streaming pipeline for order, acceptance, pickup and delivery events |
| Supply Tracking | Real-time rider state store keyed by geographic zone |
| Kitchen Models | Per-restaurant gradient-boosted models conditioned on live load |
| Travel Estimation | Two-wheeler routing with live traffic, similar to map ETA services |
| Dispatch & Batching | Optimisation service assigning riders and grouping compatible orders |
| Feature Store | Shared online features so training and serving stay consistent |
| Serving | Cached zone state with low-latency model inference at checkout |
Delivery prediction is a lesson in composing uncertain estimates and then converting them into a commitment. Any business that promises a customer a completion time — a repair, a dispatch, a service call — faces the same structure: several uncertain stages, an asymmetric cost of being late, and a decision about how much of that uncertainty to absorb rather than pass on.
A quick, no-nonsense translation of the technical terms used above.
How long the restaurant takes to cook and pack an order, heavily dependent on current load.
The wait between an order being placed and a rider being allocated to it.
The rider's journey to the restaurant to collect the order.
The journey from restaurant to customer, including the final walk to the door.
Assigning several orders to one rider to improve efficiency, at the cost of some delivery time.
Extra time deliberately added to the promise to reduce the chance of being late.
The number of riders available in an area relative to the orders needing delivery.
The range a value is likely to fall within, rather than a single expected number.