Zomato
Food delivery and restaurant discovery for 300,000+ restaurants
Zomato Architecture Blueprint
Click ▶ RUN to animate active particle streams across microservices
How Traffic Flows Through Zomato
1. Ingress & Edge Routing
User requests arrive at the edge network. Global CDNs cache static assets and media. API Gateways terminate TLS, validate JWT authentication tokens, enforce token-bucket rate limits, and scrub malicious bot traffic before forwarding to internal services.
2. Microservice Processing
Stateless domain services execute core business logic. Microservices communicate via high-performance internal gRPC/REST APIs and autoscaling worker pods, ensuring that high load on one domain never exhausts compute resources of another.
3. In-Memory Caching & Storage
Read-heavy traffic is served from in-memory Redis clusters with sub-millisecond latencies, protecting primary databases. Persistent databases (PostgreSQL, Cassandra, DynamoDB) maintain ACID consistency for financial ledgers, user accounts, and immutable state records.
4. Asynchronous Event Streams
Heavy operations (notifications, audit logging, analytics, ML training, fan-out delivery) are decoupled into durable event logs like Kafka and SQS. This prevents user-facing requests from blocking on slow external networks.
Study Zomato's database schemas, capacity math & production contracts
Beyond the visual blueprint, explore the exhaustive 7-section engineering whitepaper with real DDL schemas, API endpoints, failure mitigation matrices, and 45-minute FAANG interview scripts.
Three-Sided Dynamic Matching Under Tight Hunger Latency Budgets
Food delivery is a three-sided marketplace (Customer, Restaurant, Delivery Partner). If a driver is dispatched too early, they waste 15 minutes waiting in the restaurant kitchen. If dispatched too late, the customer's food sits on the counter getting cold.
Zomato predicts restaurant preparation time using historical kitchen ML models. The assignment engine delays dispatching the driver so their arrival matches the exact moment the chef packs the meal.
⚖️ Architectural Trade-Offs & Decisions
Why the engineering team chose this specific stack over competing alternatives
Millions of customers polling the server every 2 seconds for rider coordinates would generate hundreds of thousands of HTTP requests per second with massive TLS header overhead. WebSockets maintain a lightweight open duplex pipe, pushing coordinates only when the rider moves >20 meters.
Orders cannot jump states arbitrarily (e.g. an order cannot be "Delivered" before it is "Picked Up"). A formal state machine backed by ACID transactions ensures race conditions (like simultaneous cancellations and pickups) are handled safely.
The New Year's Eve Midnight Order Spike (2020)
At 8:30 PM on New Year's Eve, Zomato's order processing system collapsed under 4,000 orders placed every second, displaying checkout failure screens across major Indian metros.
A shared relational database cluster ran out of connection pool threads when concurrent checkout transactions waited on external bank payment gateway timeouts.
Zomato decoupled the checkout pipeline using Kafka: customer orders are accepted into durable queues immediately, while payment confirmations and kitchen notifications are processed asynchronously.
📋 Complete Microservice Specifications
Every service in the Zomato ecosystem with production tech stacks and failure impact
| Component | Tier / Layer | Tech Stack | Production Function | Status / Chaos |
|---|---|---|---|---|
| Customer App | CLIENT | iOSAndroidWebSockets | Food ordering app browsing restaurants and tracking live delivery ETA | |
| Restaurant Tablet | CLIENT | Android TabletREST | Merchant tablet receiving orders and transmitting kitchen prep time updates | |
| Delivery Partner App | CLIENT | AndroidGPS | Mobile app broadcasting delivery rider GPS location every 5 seconds | |
| API Gateway | GATEWAY | KongGo | Gateway managing rate limiting, session auth, and order routing | |
| Search & Discovery | SERVICE | ElasticsearchLucene | Elasticsearch cluster powering restaurant search, cuisines, and dish recommendations | |
| Order Service (State Machine) | SERVICE | JavaSpring BootPostgreSQL | Finite State Machine managing order transitions (CREATED -> PREPARING -> PICKED_UP -> DELIVERED) | |
| Payment Gateway | SERVICE | RazorpayPaytmStripe | Payment service supporting UPI, credit cards, net banking, and cash on delivery | |
| Rider Location Engine | SERVICE | GoRedis GeoOSRM | Ingests delivery partner GPS coordinates and calculates road network ETAs | |
| Dynamic Dispatcher | SERVICE | PythonRayOR-Tools | ML matching engine assigning orders to optimal nearby delivery partners | |
| Notification Service | SERVICE | FCMAPNsGupshup | Dispatches push notifications and SMS updates on order status changes | |
| Redis Cache | CACHE | Redis | In-memory cache for restaurant menus, active rider locations, and user sessions | |
| Kafka Order Events | QUEUE | Apache Kafka | Event streaming bus distributing order updates to analytics, billing, and rider apps | |
| PostgreSQL Orders DB | DATABASE | PostgreSQL | Relational database storing immutable order records, receipts, and user histories |