Swiggy System Design, Step by Step

Loading the interactive diagram…

How Swiggy works, step by step

How a food delivery app works: which restaurants can reach you, predicting prep and delivery time, and assigning delivery partners.

Clients

Customer app: Client · Documented. Where people browse restaurants, pay and follow their order.
Restaurant app: Client · Documented. Where restaurants receive orders and mark them ready.
Delivery partner app: Client · Documented. Tells delivery partners what to do next and reports where they are.

Edge

API gateway: Gateway · Hypothetical. Single way in for the three apps.

Discovery

Home and listing: Service · Documented. Builds the list of restaurants you can order from right now.
Serviceability: Service · Documented. Decides which restaurants can deliver to you, and how long it would take.
Recommendations: Service · Documented. Suggests what you might want to eat.

Ordering

Cart and checkout: Service · Hypothetical. Holds your items and shows the price and delivery time.
Order service: Service · Hypothetical. Owns each order from placement to delivery.
Payments: Service · Hypothetical. Takes payment before the order goes to the restaurant.
Payment provider: External · Hypothetical. The outside company that moves the money.

Delivery logistics

Time predictions: Service · Documented. Predicts prep time and delivery time.
Assignment engine: Service · Documented. Chooses the delivery partner, and when to send them.
Delivery tracking: Service · Documented. Knows where each delivery partner is and what they're doing.
Kabootar: Service · Assumption. Sends messages to customers, restaurants and delivery partners.

Data

Event streams: Queue · Assumption. Carries what just happened to the services that care.
Feature store: Database · Documented. Serves fresh data to machine learning models quickly.
Transactional databases: Database · Documented. The permanent record of orders and other live data.
Data lake: Database · Documented. Copies live data for analysis, without slowing the live databases.

Flow: Finding restaurants

You open the app. From your location, it works out which restaurants can reach you and how long each would take.

Customer app → API gateway (Show nearby food). You open the app. It sends your location to the API gateway.
API gateway → Home and listing (Home page for here). The gateway passes the request to the service that builds the home page.
Home and listing → Serviceability (Who delivers here?). Listing asks which restaurants can deliver to you. One call can cover more than 2000 restaurants, so this has to be fast.
Serviceability → Time predictions (Estimate these trips). Serviceability has already filtered pickup points by location. Now it needs a delivery time for each one left.
Time predictions → Feature store (Fresh signals). Prediction models fetch up-to-date data from the feature store, whose online side is Redis.
Feature store → Time predictions (Latest features). The data comes back within milliseconds.
Time predictions → Serviceability (Delivery times). Predictions return an estimate for each restaurant.
Serviceability → Home and listing (These can deliver). Serviceability answers with the restaurants that can reach you, and how quickly.
Home and listing → API gateway (Personalised list). Listing puts the page together, personalised for you.
API gateway → Customer app (Restaurants near you). The app shows the restaurants. You see only places that can actually reach you.

Flow: Placing an order

From the cart to a confirmed payment. The cart re-checks delivery, because things may have changed since you started browsing.

Customer app → API gateway (Open my cart). You've picked your food and open the cart.
API gateway → Cart and checkout (Price this cart). The gateway passes it to the cart service.
Cart and checkout → Serviceability (Still deliverable?). Serviceability runs again here. A restaurant that could reach you a few minutes ago might not now.
Serviceability → Cart and checkout (Yes, deliverable). It still can.
Cart and checkout → Time predictions (How long will it take?). Swiggy predicts the delivery time at the cart. This is the promise you see, and the assignment system relies on it too.
Time predictions → Cart and checkout (Promise: about 35 min). The estimate comes back. The 35 minutes is just an example.
Cart and checkout → API gateway (Total and time). The cart returns the price and delivery time.
API gateway → Customer app (Your total and time). You see the total and delivery time, and press Pay.
Customer app → API gateway (Pay and place order). The app sends your order and payment choice.
API gateway → Order service (Create this order). The gateway passes it to the order service.
Order service → Payments (Take payment). The order service asks payments to collect the money.
Payments → Payment provider (Charge customer). Payments asks an outside provider to move the money.
Payment provider → Payments (Payment approved). The provider confirms it.
Payments → Order service (Paid). Payments tells the order service the money arrived.
Order service → Transactional databases (Save order). The order is saved in the transactional databases.
Transactional databases → Order service (Saved). It's stored safely.
Order service → Event streams (Order placed). The order service announces the new order. Restaurant and assignment work can begin without holding you up.
Order service → API gateway (Order confirmed). The order service replies to the gateway.
API gateway → Customer app (Order placed!). You see your order confirmed and start waiting for food.

Flow: Restaurant confirms, partner assigned

Your order reaches the restaurant, which confirms it, and the assignment engine chooses a partner and when to send them. Nobody is waiting on an answer here, so this flow runs one way.

Event streams → Kabootar (New order). The order event reaches the communication platform.
Kabootar → Restaurant app (New order for you). The restaurant app gets the order by push notification. It also polls the API, in case a push is missed.
Restaurant app → API gateway (Order confirmed). The restaurant accepts it and starts cooking.
API gateway → Order service (Restaurant confirmed). The confirmation reaches the order service.
Order service → Event streams (Order confirmed). The order service announces it, which wakes the assignment engine.
Event streams → Assignment engine (Find a partner). Assignment now weighs nearby partners, their current work and which orders could share a trip.
Assignment engine → Time predictions (When is food ready?). It asks for the prep time. Cooking and the partner's trip happen side by side, so timing matters.
Time predictions → Assignment engine (Prep time estimate). With this estimate, assignment can hold back, so that the partner doesn't stand around waiting. Swiggy reports about 25% less waiting from this.
Assignment engine → Kabootar (Offer to this partner). A partner is chosen, possibly with a second nearby order in the same trip.
Kabootar → Delivery partner app (New delivery). The partner's app moves to its next state, and alerts them.

Flow: Tracking your food

The partner's phone reports where it is, your app shows it on a map, and you're told when the food arrives.

Delivery partner app → API gateway (Location ping). The partner's app keeps reporting its location.
API gateway → Delivery tracking (Partner is here). The gateway passes it to delivery tracking, which knows where every partner is and what they're doing.
Delivery tracking → Time predictions (Update the ETA). Location pings feed the models. The last-mile model takes over once food has been picked up.
Customer app → API gateway (Where's my food?). Meanwhile, you open the tracking screen.
API gateway → Delivery tracking (Latest for this order). The gateway asks tracking for your partner's position.
Delivery tracking → API gateway (Position and ETA). Tracking answers with where they are, and when they should arrive.
API gateway → Customer app (Partner on the map). You see your food moving on the map, with an updated arrival time.
Delivery partner app → API gateway (Delivered). The partner marks the order as delivered.
API gateway → Order service (Mark delivered). The order service records the last state.
Order service → Event streams (Order delivered). It announces that the order is complete.
Event streams → Kabootar (Tell the customer). The communication platform picks that up.
Kabootar → Customer app (Enjoy your meal!). You get the news, and the order is complete.

Flow: Learning from orders

After the order, data moves on so that the next prediction is better. This work runs in the background and nobody waits for it, so this flow runs one way.

Order service → Event streams (Order events). Things that happen to an order become events.
Event streams → Feature store (Near-real-time features). Flink SQL jobs turn streams into fresh features, and Kafka carries them to the feature store.
Order service → Transactional databases (Order record). Orders are also saved in the transactional databases.
Transactional databases → Data lake (Copy the changes). Change data capture copies each change to the data lake, where Spark jobs can build the offline features and analysis, without loading the live databases.

Sources

HowItScales is not affiliated with the companies shown. Components marked Assumption or Hypothetical are not confirmed by the company.

Swiggy system design: how it works