How Zomato Built Real-Time Order & Delivery Tracking
Introduction
Customer opens food-delivery app.
They pick a restaurant.
They place their order.
Then they wait.
But the wait is very different when the app says:
We are preparing your order.
Then:
Delivery partner allocated.
And then:
“Your order has been collected!
Then the map begins to move.
Following that:
Arriving in 8 minutes.
This appears to be simple to the customer.
But for the team of engineers that built it, it's not that simple.
In a modern food delivery platform, you need to coordinate restaurants, customers, delivery partners, payments, maps, order state, estimated delivery time, notifications, external services, and back end infrastructure, often with traffic changing every second.
Zomato has been publicly sharing with the engineering community a number of insights into the systems that power its food-delivery experience, from ETA prediction, to address and location accuracy, to high-volume order processing, monitoring, resilience, and real-time data systems.
What’s interesting to note is not just how Zomato tracks a delivery partner.
It’s how a company makes a world of ever-changing events predictable in the digital experience.
Why is Real-Time Food Delivery So Hard?
A transaction is not a food-delivery order.
A sequence of dependent events.
The simplified flow would look something like:
Orders by customers
↓
Restaurant confirmed order
↓
Food preparation starts
↓
Appointed delivery partner
↓
Partner heads to restaurant
↓
Order is collected
↓
Partner visits customer
↓
Delivery of order
Each stage changes the state of order.
And each state can influence the expected delivery time of the customer.
So the engineering challenge is not merely:
“Show the delivery partner on map.
It's:
"Continually keep track of a changing physical process and convey that state to customers in a useful way."
This requires a lot more than GPS coords.
The Map Is More Important Than ETA
One of the most interesting facts from Zomato's engineering work is the fact that Estimated Time of Arrival is at the core of the ordering experience.
Zomato says ETA is used to browse menus, select restaurants, assign delivery partners, track orders and inform customers about delays. Its Time Microservice owns the ETA computation and disseminates the information to other services.
This is an important lesson in product.
Map is visual.
ETA is now operational.
A customer really doesn’t care that a delivery partner is traveling 312 meters east.
They worry about dinner coming in:
18 minutes or 42 minutes.
ETA is More Than “Distance ÷ Speed”
A simple delivery system could calculate:
ETA = distance / average speed
That's not how real world delivery goes.
The ETA calculations are not just based on the Delivery Partner ETA but also consider Kitchen Preparation Time, dynamic buffers and local delivery-partner arrival times, Zomato said. Its engineering article also lists variables including customer demand, traffic, road closures, repairs, delivery-partner supply, weather, and system stress.
So a delivery estimate is best thought of as a constantly changing prediction.
In a conceptual sense:
Final ETA = prep time + travel time + dynamic conditions + operational uncertainty
The precise implementation can vary over time, but the engineering principle is powerful:
A good estimate should be a representation of how the system actually behaves, not just the route shown on a map.
Kitchen Time Is Important Too
Imagine two restaurants.
Restaurant A 5 km
Restaurant B is just 500 meters away.
You might think that Restaurant B will always be faster.
Not necessarily.”
Zomato’s engineering work on Food Preparation Time shows why it’s hard: different restaurants and different dishes have very different preparation characteristics, so it’s not just distance that determines when food will actually arrive.
This introduces yet another dependency.
The delivery system must understand:
When will the food be done?
not only:
How long will the rider be there?
Hence ETA is not a simple mapping feature but a product level prediction problem.
Location accuracy is a product matter
A delivery partner could have perfect GPS coordinates and still struggle to find the customer.
Why is that?
Real cities are messy.
Multiple towers in apartment buildings.
All of the entrances to office campuses.
Roads may not be well-marked.
Phones can get inaccurate GPS readings.
The pinned location on the customer’s side could be close to the right building, but not the right entrance.
Zomato has said it worked on improving location accuracy by identifying and mapping high-volume geographical entities such as offices, colleges, apartments and hospitals. The company also used customer address data with latitude and longitude information, and feedback loops to improve its points-of-interest mapping.
This is a useful insight.
Last mile delivery is not just a routing problem. It is a question of knowing where it is.
The “Last 100 Meters” May Be Harder than the First 5 Kilometers
Assume the delivery partner is already outside the customer’s apartment complex.
The app states:
50 meters from it.
But it still takes five minutes to get there.
Why that?
For:
The right gate could be on another road.
Parking can be a pain.
The building may have more than one entrance.
The customer may be required to provide floor/tower information.
The delivery partner may have to call.
Zomato’s location work specifically targeted the last mile interactions. Published results show improved address accuracy, fewer partner-to-customer calls and shorter “handshake” times between delivery partner and customer.
This is a good example of the difference between being technically correct and being useful for business.
A coordinate can be technically correct but operationally incorrect.
A Useful Mental Model: Events, State, and Prediction
There are three concepts we can use to understand a modern delivery system.
1. Upcoming Events
Something is happening.
For example:
Order generated
Restaurant confirmed.
Began preparing food
Delivery partner selected
Order received
Changed location
order received
2. Condition
The state is the same.
For instance:
Order Number: 12345
Restaurant: In preparation
Partner: Designated
Pickup: TBD
Customer location: Verified
ETA 26 mins
3. Forecast
The system predicts what happens next.
For example:
Coming in at 8.42 pm
The prediction can be updated, when new events arrive.
This is the core of real-time systems.
Location Data Only Works If the System Can Use It
Location information can be created by the phone of the delivery partner.
But raw location data isn’t sufficient.
The backend has to figure out:
What is the order of this location?
Is the partner doing anything?
Is your partner here at the restaurant?
Has the order been collected?
Is the partner coming to the customer?
Is the delivery in the expected area of destination?
Do you want to recalculate the ETA?
Hence the system converts raw signals into business events.
Conceptually speaking:
cell-phone
↓
Location update
↓
Back-end processing
↓
Order Status
↓
Re-Calculate ETD
↓
Customer-facing changes
That pipeline has to be reliable when thousands of things are happening at the same time.
APIs for a Connected Delivery Workflow
Delivery experience is another big integration problem.
Zomato’s developer documentation currently describes APIs and webhooks for order-management workflows, including order confirmation, order rejection, order readiness, order pickup, delivery-partner assignment, delivery completion, and order-status notifications.
That speaks to something important about the architecture.
No delivery platform can be an only stand alone application.
Components must talk to each other.
For instance:
Restaurant system
needs to talk to:
* System order
which is speaking to:
Delivery system
which says:
Customer Facing Apps
and other services like payments, notifications, mapping, analytics may come into play along the way.
That's why modern delivery products look more like distributed systems than they do like simple websites.
The Backend Needs to Survive Peak Traffic
A delivery platform may be perfectly healthy at 2:00 PM and dramatically harder to operate at 9:00 PM.
The most severe case occurs at high demand events.
Zomato has publicly documented engineering preparation around New Year’s Eve.
The company saw over 4,000 orders per minute on NYE 2020 and almost doubled that rate on 2021. Its engineering teams said they use circuit breakers, feature kill switches, database bottleneck analysis, monitoring and alternate service providers to make the system resilient under extreme demand.
The lesson is very simple:
Scaling is more than simply adding servers.
It's about designing for failure as well.
What Happens If Something Goes Wrong?
Here’s something to consider:
· A payment provider is late.
· The database begins to time out.
· A third-party communications service is out.
· Sudden spikes in request volume.
· A particular service is overloaded.
A fragile system can turn a small problem into a platform-wide outage.
Isolated failures in resilient system.
Zomato has listed practices such as:
· Circuit Breakers,
· Feature kill switches
· Database bottleneck warning
· Logging in Real-Time
· Monitoring systems
· Other Third Party Providers
These are not “additional” engineering features.
They belong to the product.
Reliability is a customer experience feature when millions of users depend on an application.
Real-Time Systems Need More Than Just Real-Time Data
Another important difference:
Real-time data does not equal a useful real-time experience.
You could gather a massive amount of events and still produce a bad product.
The system has to decide:
· What events matter?
· How often should information be updated?
· What data should trigger a change in the ETA?
· What is the customer seeing?
· What will be left in the house?
· Was passiert bei fehlenden Daten? Aus fehlenden Daten wird:
· How do we deal with stale data?
This is where backend architecture, product design, data science and infrastructure start to intersect.
Machine Learning May Become Part of the Delivery Experience
Zomato has also open-sourced engineering work on machine-learning systems that do things like predict how long it will take to deliver food in real time.
Its scalable ML architecture has involved real-time features generated from event streams, using Apache Kafka and Apache Flink in its published architecture for streaming feature computation, with Redis and other storage systems supporting feature access and model serving workflows.
This is a larger scale evolution.
A delivery app is no longer just:
database + API + mobile app
It can turn into:
events + streaming + machine learning + prediction + APIs + observability + infra
The user still sees a blank screen.
But underneath, the system might be doing sophisticated computation.
Real-time tracking is more of a coordination problem
The best way to think about Zomato’s delivery tech is not to:
“They made a living map.
It is:
They built systems for continuous alignment of people, software, data and physical operations.
Imagine all the pieces that need to fall into place:
Client
Must be accurate on status and expectations.
Diner
Realistic preparation times needed.
Delivery partner
Needs proper location & routing information.
Back-end
Requires reliable state and event handling.
Predictive engines
Require changing signals.
Infrastructure
Must remain available during traffic peaks.
Product teams
“Have to make all of this into a simple user experience.
That’s the real engineering problem.”
What Zomato Can Teach Startups
You don’t need millions of orders to learn from this architecture.
The same is true of far smaller products
Lesson 1: Model the workflow before you build features
Real Business Process Mapping
Query:
What takes place?
Who makes them do it?
Which system owns the state?
What’s next?
This prevents teams from building isolated features.
Lesson 2: Designing for change
Real systems do not operate under ideal conditions.
Users lose connection.
Third-party APIs are unreliable.
Databases get slow.
Traffic spikes.
We all make mistakes.
Design your architecture to change and failure.
Lesson 3: Early investments in observability
In case you didn't know:
· what's going wrong?
· where does latency come from
· what service is too busy.
· number of requests that are timing out
your team is debugging in the dark.
Monitoring and logging aren’t just infrastructure concerns.
They shorten the way between:
something went wrong
and -
We know what the problem was.
Lesson 4: Don’t confuse UI and system reliability
A pretty tracking map doesn’t solve a flaky backend.
Likewise, even if the backend is correct, the information can still be presented in a manner that leads to a poor customer experience.
Both are linked by strong products.
Lesson 5: Optimizing the real bottleneck
Zomato’s engineering publications have a pattern that repeats itself:
Identify the bottleneck → measure → change the system → measure.
Whatever the constraint (accuracy of ETA, quality of location, throughput or data processing), the engineering process begins with the real constraint.
That’s a smarter approach than throwing in technology just to be trendy.
A Simpler Architecture for an Evolving Delivery Product
A smaller startup might start with something like:
Customer Applications
↓
Layer API
↓
Service Order
↓
Database
alongside;
Delivery Partner Application
↓
Location / Event API
↓
Order + Shipping Status
And then:
Service ETA
↓
Customer Application
As the business expands, other components may be needed:
· Stream Events
· Cache
· Background processes
· Notification Service
· Observability
· Data pipelines
· ML services
· Geospatial processing
· Failover mechanisms
The trick is to evolve the architecture in real scale and real business needs.
“On day one, you don’t need Zomato’s architecture.
You require an architecture capable of evolving to your business' next constraint.
The Bigger Lesson: Don’t Let the Customer See the Complexity
This could be the most important product lesson for Zomato.
The customer needn’t understand:
· micro-services
· streams of events
· ML (ML)
· message queues
· caching
· circuit breaker *
· location systems
What they want to see is:
"Order coming in 7 minutes."
Great engineering is often invisible.
When complex systems work, the customer experiences simplicity.
This is the aim.
Final thought for founders
One feature is the lack of real time order tracking.
It is the visible part of a much larger system consisting of:
· order status
· Geolocation data
· Application Programming Interfaces (APIs)
· ETA forecast
· restaurant industry
· logistics of delivery
· event-handling
· infrastructure
· observation
· failure recovery,
Zomato’s engineering publications give us a useful window into the relationship between these individual problems — from ETA prediction to location accuracy to high-volume operations and real-time data systems.
The bigger lesson for startup founders is simple:
Build the technology to enable the business workflow, not the other way around.
When your product requires real-time operations, integrations, automation and complex business logic, thoughtful custom software architecture can become a huge competitive advantage.
KarmaKoders helps startups and growing businesses turn complex workflows into scalable web applications, backend systems, APIs and custom software platforms.
Need real-time workflows, integrations or scalable backend architecture to build a product? Discover our Custom Software Development Services.
Zomato’s engineering publications give us a useful window into the relationship between these individual problems — from ETA prediction to location accuracy to high-volume operations and real-time data systems.
The bigger lesson for startup founders is simple:
Build the technology to enable the business workflow, not the other way around.
When your product requires real-time operations, integrations, automation and complex business logic, thoughtful custom software architecture can become a huge competitive advantage.
KarmaKoders helps startups and growing businesses turn complex workflows into scalable web applications, backend systems, APIs and custom software platforms.
Need real-time workflows, integrations or scalable backend architecture to build a product? Discover our Custom Software Development Services.