Guides

Swiggy Architecture Explained: How Swiggy Runs Food and Grocery Delivery

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

Short answer: Swiggy runs on AWS. Its web front end uses server-side rendering services on EC2 and Kubernetes behind Kong and HAProxy, and static pages from S3 with CloudFront (2025). Microservices talk through Kafka, the event backbone. Transactional data sits in stores such as DynamoDB, whose change streams feed Swiggy's data lake. Real-time features run on Rill, a Flink platform on Amazon EMR.

Suppose you order groceries on Swiggy Instamart

It is Sunday evening in Gurugram. You order milk and vegetables on Instamart. In simple terms:

1. The Swiggy app or website calls Swiggy's services on AWS; web pages come from server-side rendering services or from S3 through CloudFront.
2. Kong and HAProxy route traffic, and can send a small percentage to a new version first.
3. Order, cart and delivery microservices handle your request and publish events to Kafka.
4. Transactional data is stored in databases such as DynamoDB.
5. Rill (Flink) uses live events, for example to keep state in Redis or Valkey for real-time features.
6. Klaxon watches business metrics in real time and alerts teams if orders suddenly drop.

What architecture style does Swiggy use?

Swiggy uses event-driven microservices with strong release safety and cost control.

1. Event backbone: Kafka connects microservices and real-time analytics.
2. Controlled rollouts (2025): SSR services shift traffic from 1% to 100% via Kong/HAProxy while watching latency and errors; static pages use CloudFront continuous deployment with a canary distribution.
3. Cost engineering: Swiggy cut CloudFront costs by about half with smaller error pages, compression and caching, and cut ALB data costs with compression in its ingestion service (2024).
4. Change data capture: DynamoDB Streams feed a CDC system that copies transactional data into the data lake.

Swiggy architecture diagram (public parts)

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

What does Swiggy use? Main technologies

Which cloud provider does Swiggy use?

Swiggy runs on AWS (EC2, S3, CloudFront, ALB, DynamoDB, EMR, SES).

How did Swiggy cut its CloudFront bill by about half?

A set of small changes that added up to about 52% savings on CloudFront:

1. Smaller error pages: one error HTML page was 179 KB. Shrinking it to about 2.1 KB alone cut daily CloudFront cost by about 30%, because error pages are served very often.
2. Minify and compress: smaller HTML, CSS and JavaScript means fewer bytes sent.
3. Better caching: more requests answered from the edge.
4. Move heavy screens: high-traffic chat screens moved from CloudFront to ImageKit, saving another 35% a month.

How a front-end release rolls out (2025)

1. For server-rendered pages, Kong and HAProxy send 1% of traffic to the new version, then more, up to 100%, while latency and errors are watched.
2. For static pages in S3, CloudFront continuous deployment uses a separate canary distribution; production traffic is then shifted to a canary S3 path, starting at about 10%.
3. ImageKit falls back between production and canary asset folders so users never see missing files.

How it started: logistics and serviceability

1. Earlier, Swiggy re-architected its logistics systems and built a serviceability platform that decides, at high scale, which restaurants can deliver to you.
2. Its "Where is my order?" system uses machine learning for delivery time prediction.
3. Exact dates and details of these older systems are not publicly shared.

How does Swiggy store data?

1. DynamoDB for transactional data, streamed into the data lake via CDC.
2. S3 for static web assets and data lake files (Delta).
3. Redis / Valkey for real-time state written by Rill.
4. Other main databases are not publicly shared.

How does Swiggy monitor its systems?

1. Klaxon: real-time business monitoring using Kafka, Rill, Databricks and Snowflake, with alerts by email (AWS SES).
2. A unified production-changes timeline helps reduce time to detect and fix issues.
3. Rollouts are watched for latency and error rates before each traffic step.

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

Suppose you want to build "KiranaNow", a 20-minute grocery delivery app for one city. 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 with weighted target groups for canaries.
2. Services on EKS.
3. Events via SQS or MSK (Kafka).

3. Storage and databases

1. DynamoDB for orders, with Streams.
2. Aurora for stores; ElastiCache for stock and carts.
3. S3 + CloudFront for images.

4. Monitoring

1. CloudWatch alarms on order rate drops.
2. X-Ray traces.

Request flow diagram

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

Swiggy versus our AWS design