01 / The problem
What makes the decision difficult
Sparse maps, kitchen delays and delivery-partner route choices make a single deterministic ETA unreliable.
Zomato-inspired
Food Delivery · Public engineering case
Zomato described moving from a map-graph approach toward a tree-based ETA model that can learn from actual delivery behavior. The system must remain accurate at high throughput while paying special attention to long-tail delays that damage customer trust.
7 min read
System blueprint
From evidence to action
The case brief
The model is only one part of the story. A useful case study makes the problem, evidence, trade-offs and final action easy to explain.
01 / The problem
What makes the decision difficult
Sparse maps, kitchen delays and delivery-partner route choices make a single deterministic ETA unreliable.
02 / The approach
How the system creates a useful output
Combine operational and geospatial features in a low-latency tree ensemble, then monitor both average and extreme errors.
A closer look
Four notes to help you reason about the case instead of simply memorizing its stack.
Why this is genuinely hard
A delivery ETA is not one journey measured by a map. It combines kitchen preparation, a courier reaching the restaurant, pickup and handoff friction, and travel to the customer. Each stage follows a different clock: kitchens slow during a rush, courier supply changes by neighborhood and roads or weather alter travel after the order is placed. In dense or poorly mapped areas, an experienced courier may not follow the suggested route. Errors are asymmetric too. A padded estimate may discourage an order, while an optimistic promise creates a visible breach and support contact. The model must update as the operation changes yet serve predictions in milliseconds at high traffic. Average error is insufficient because rare twenty-minute misses can dominate customer trust.
Design decisions that matter
A route engine offers an interpretable physical baseline, while a tree ensemble learns behavior the map misses; keeping both lets the learned model correct rather than forget geography. More real-time features may improve rain or surge accuracy, but every lookup adds latency, freshness risk and cost, so feature parsimony is part of model quality. One end-to-end ETA is simple to serve, whereas separate preparation, pickup and travel estimates make diagnosis and mid-order updates easier but can compound errors. MAE treats early and late misses symmetrically; quantile or asymmetric losses reduce damaging underestimates at the cost of longer displayed times. A global model shares data across cities, while localized models capture distinct road and kitchen patterns. Evaluation must expose both typical error and breach rates by operating condition.
Where a project like this can fail
Build a smaller version yourself
Build an ETA lab with one row per completed order and columns for order time, restaurant and zone IDs, item count, preparation estimate, courier-to-restaurant distance, customer distance, weather category, dispatch delay, pickup wait and actual completion time. Split chronologically so future orders never inform past predictions. Compare a distance-and-hour baseline, a tree regressor and a quantile model. Deliver a notebook, compact evaluation dashboard and five worked order timelines. Report MAE, two- and five-minute accuracy, underprediction breach rate and the same metrics by zone, rush hour and rain. Add a feature-ablation table showing whether each latency-expensive signal earns its cost, plus a stable rule for refreshing ETA after pickup.
How the system works
Read this as a design walkthrough, not a recipe. In a real project, each step is tested, revised and connected to the next one.
Separate food preparation, pickup, travel and handoff. Each phase has different features, uncertainty and opportunities for recalibration.
A delivery partner may take a route that differs from the map's suggestion. Train on operational outcomes so the estimate reflects the system people actually use.
ETA appears during browsing and checkout, so inference must be fast and resilient at high QPS. Feature parsimony can be more valuable than a marginally larger model.
Mean error can look healthy while catastrophic misses remain. Add specialized objectives or ensemble members for rain, sparse regions and long-tail events.
A practical stack
Real tools you can learn and recognize
What this case teaches
The goal is not to copy a company's private implementation. It is to understand the reasoning well enough to design, test and explain your own version.
What to measure
A model is only as useful as its evaluation
Share of orders predicted within practical customer-facing bands.
Typical absolute error and the variability around it.
Orders missing the promise by more than a critical threshold.
What to remember
Ideas worth carrying into your own project
Read the original work
This is an independent learning adaptation. Use the sources to inspect the company's own explanation, evidence and technical detail.
Next case study
This independent learning case is inspired by public industry patterns and is not affiliated with or endorsed by the named company.