Guides

Zomato Architecture Explained: How Zomato Delivers Food Orders at Scale

By Ravindra Bagale, AWS & DevOps trainer · LinkedIn · Published: 18 October 2026 · Last updated: 18 October 2026

Short answer: Zomato runs on AWS as microservices on EKS and ECS (often on Spot EC2), connected through an Envoy service mesh, Kafka and MQTT (2024). Its billing platform moved from TiDB to Amazon DynamoDB in 2024, cutting response times by about 90%. Restaurant search uses Solr (2023). Monitoring moved to VictoriaMetrics in 2024, handling 2.2 billion active time series on New Year's Eve.

Suppose you order biryani on Zomato

It is New Year's Eve in Kolkata. You search for biryani and place an order. In simple terms:

1. Your app calls Zomato's microservices on AWS, linked by an Envoy mesh.
2. Search finds nearby restaurants using Solr (Zomato handles about 100 million search queries a day).
3. You place the order; order services publish events to Kafka.
4. The billing platform consumes the order event and writes a ledger to DynamoDB.
5. Live updates (like order status) can flow over MQTT.
6. Metrics from every service go into VictoriaMetrics and Grafana.

Search deserves a special mention. In 2023 Zomato's Solr schema relied heavily on dynamic fields, which caused poor performance and high cost at peak times. Quick fixes (a newer Solr version and doc_values for sorting and aggregation fields) helped, but the real fix was redesigning the schema and query style. That made search more resilient, more scalable and cheaper while serving about 100 million queries a day. On busy nights like New Year's Eve, these improvements, the DynamoDB billing move and the VictoriaMetrics monitoring stack all work together so that orders keep flowing.

What architecture style does Zomato use?

Zomato today uses event-driven microservices on AWS.

1. Microservices with Kafka (2024): the billing platform is both a producer and consumer of Kafka events, so services stay loosely coupled.
2. Managed databases (2024): moving billing to DynamoDB removed the work of running TiDB clusters and handled traffic spikes without over-provisioning.
3. Envoy mesh and EKS: infrastructure metrics come from Envoy mesh, cAdvisor, EKS, Kafka and MQTT (2024).
4. Cost aware: the old Prometheus fleet ran as ECS services on 100% Spot EC2 instances.

Zomato architecture diagram (public parts)

This diagram shows only what Zomato or its partners have shared publicly. Press Play to follow a request step by step.

What does Zomato use? Main technologies

Which cloud provider does Zomato use?

Zomato runs on AWS. It uses EC2, ECS, EKS, multi-AZ setups and DynamoDB.

Why did Zomato move billing from TiDB to DynamoDB?

The 2024 move:

1. The billing platform handles post-order work: it consumes order events from Kafka and produces a ledger for many business uses.
2. TiDB needed several components to be run and tuned: TiDB servers, the Placement Driver, TiKV storage and TiFlash. Spikes meant costly over-provisioning.
3. DynamoDB is fully managed and serverless, so it scales with traffic.
4. Zomato used a single-table design, keeping related data together so one read returns everything needed.
5. Results: about 90% lower average response time, throughput up to 8,000 requests per minute (four times the old design), near-real-time billing and lower total cost.

The lesson for learners: a managed database can remove a lot of operational work, but you must design your keys and access patterns carefully first.

How it started: monitoring and databases before 2024

1. In 2018 Zomato monitored with a single Grafana server on EC2, one Prometheus server and New Relic.
2. It then grew to 144 Prometheus servers with Thanos, multi-AZ, on ECS Spot instances, before moving to VictoriaMetrics in 2024.
3. Billing first used TiDB, a distributed SQL database, before moving to DynamoDB.
4. In 2023 Zomato reworked its Solr schema to remove dynamic fields that slowed search at peak times.

How does Zomato store data?

1. DynamoDB: billing ledger and other business-critical services; billing throughput rose to 8,000 requests per minute, four times the old design.
2. Solr: search indexes.
3. VictoriaMetrics: metrics storage.
4. Main order databases and image storage are not publicly shared.

How does Zomato monitor its systems?

1. VictoriaMetrics (2024): 2.2 billion active time series, 17.5 million samples per second ingested on New Year's Eve 2024.
2. The clean-up cut active time series by 40% and removed 200 unused dashboards.
3. Grafana dashboards, load-tested with k6.

If we built an app like Zomato on AWS (illustrative)

Suppose you want to build "DabbaGo", a tiffin delivery app for offices. Here is a simple AWS layout.

1. Network: VPC, subnets, route tables, gateways

1. Create one VPC with CIDR 10.0.0.0/16 in the Mumbai region (ap-south-1).
2. Use two Availability Zones (A and B), so one AZ failing does not stop the app.
3. In each AZ make three subnets: public (load balancer, NAT gateway), private app (your code) and private data (databases, cache).
4. Attach one internet gateway (IGW) to the VPC. Public route table: 0.0.0.0/0 → IGW. This route is what makes a subnet public.
5. Private app route table: 0.0.0.0/0 → NAT gateway, so servers can download updates but nobody can connect in from the internet.
6. Private data route table: only the local VPC route. Use VPC endpoints to reach S3, DynamoDB and SQS without going over the internet.

2. Compute: where the code runs

1. ALB in public subnets.
2. Services on EKS with Spot nodes for stateless work.
3. Order events through SQS or MSK.

3. Storage and databases

1. S3 + CloudFront for menu photos.
2. DynamoDB for orders and billing.
3. Aurora for restaurants; OpenSearch for search; ElastiCache for menus.

4. Monitoring

1. Amazon Managed Prometheus + Grafana, or CloudWatch.
2. Alarms on order delay.

Request flow diagram

Press Play. The numbered list below the diagram lights up with each step.

Zomato versus our AWS design