Design food delivery (DoorDash / Swiggy)

For this problem, we'll design browsing nearby restaurants, placing and paying for an order, the restaurant accepting it, assigning a delivery partner, and tracking it to the door. We'll leave grocery, scheduled orders, ads and restaurant onboarding for later. Interviewers like this one because it looks like Uber for the first ten minutes and then turns out to be different: the food has to be cooked first, so the clock that matters is the kitchen's, not the partner's. Candidates who copy their Uber answer assign a partner the instant the order lands, and the partner stands at the counter for twelve minutes.

011. Understand the problem

Functional requirements

Here's the scope I'd agree on in the first five minutes. The core requirements are:

1. Customers should be able to browse restaurants that deliver to them, with menus and an estimated delivery time.
2. Customers should be able to place and pay for an order.
3. Restaurants should be able to accept or reject an order and mark it ready.
4. The system should assign a delivery partner, who picks the order up and delivers it.
5. All three apps should see the order's status in real time, and the customer should see the partner on a map.

At this point, ask your interviewer three questions: "Are all partners ours, or do some restaurants run their own fleet? Can one partner carry two orders? Do we take the money before or after the restaurant accepts?" Each answer moves the design. I'll assume our own fleet, one order per partner for the main design, and authorise-then-capture.

Non-functional requirements

1. Orders and payments are exactly once. Two taps on "Place order", or a retry on a bad network, must still be one order and one charge. Every charge must match an order.
2. Browsing is fast. The restaurant list loads in under 300 ms at p99. People browse about 20 times for every order they place.
3. The ETA is honest. The promised time is the product. We want the partner to arrive at the restaurant within about 2 minutes of the food being ready, in either direction.
4. It survives the dinner peak. About 5 million orders a day, a dinner peak of 3x the average, 300k restaurants and 500k partners online at peak.

022. The set up

Plan the approach

We'll build the design one functional requirement at a time, adding only the boxes each one needs. Then we'll use the non-functional requirements to drive the deep dives: exactly-once maps to the state machine and payments, honest ETAs map to dispatch timing and partner choice, fast browsing maps to search, and the real-time requirement maps to tracking.

Core entities

Start with the nouns. We'll fill in fields as we need them.

• Customer: who orders, with saved addresses.
• Restaurant: location, delivery area, open hours, and a live signal of how busy the kitchen is.
• Menu item: name, price, in stock or not. Read-heavy, changes a few times a day.
• Order: customer, restaurant, a snapshot of items and prices at checkout, total, address, assigned partner and a state.
• Partner: status (OFFLINE, FREE, ASSIGNED, DELIVERING), vehicle, and latest location.
• Address: the drop point, which turns out to be harder than it looks (see the follow-ups).

API

One endpoint per requirement, plus the partner's location stream.

GET   /restaurants?lat=..&lng=..&q=pizza&cursor=..  -> { restaurants: [...], nextCursor }
GET   /restaurants/{id}/menu                         -> { items: [...], version }

POST  /orders          Idempotency-Key: 7f3c...
      { restaurantId, items: [{ itemId, qty }], addressId, paymentMethodId }
                                                     -> 201 { orderId, state: "PLACED", eta }

POST  /orders/{id}/accept     (restaurant)           -> 200 | 409
POST  /orders/{id}/ready      (restaurant)           -> 200 | 409
POST  /orders/{id}/pickup     (partner)              -> 200 | 409
POST  /orders/{id}/deliver    (partner)              -> 200 | 409
POST  /orders/{id}/cancel     (customer)             -> 200 | 409

POST  /partners/location      { lat, lng, ts }        -> 204
WS    /live                   order status + partner position

Two choices to explain. POST /orders carries an Idempotency-Key the app generates once per checkout, so a retry returns the order it already made. And the state changes are separate verbs, not a generic PATCH { state }, because each one has its own rule about who may call it and from which state; 409 Conflict means "someone else moved the order first".

Back-of-envelope estimates

All inputs are assumptions to confirm with your interviewer; the arithmetic is ours and rounded. I only do the numbers that change the design.

Notice what this tells us. Orders are low volume and high value: one well-tuned Postgres primary handles 200 inserts a second without trying. The heavy traffic is search reads and location writes, so those get their own systems, and neither touches the order database.

033. High-level design

Let's satisfy the functional requirements one at a time. Each picture is the previous one plus a few new boxes, drawn in colour; what we already had turns gray.

1) Customers should be able to browse restaurants that deliver to them

The customer opens the app and sees a list of restaurants that will deliver to where they're standing, each with an ETA. We need:

• Customer app: the client, talking to us over HTTPS.
• API gateway: one front door that checks the JWT, applies rate limits and routes each call.
• Search service: answers "which restaurants deliver here, matching this text, in what order?" and serves menus.
• Search index: a search engine (Elasticsearch or OpenSearch) with one document per restaurant: location, delivery area, cuisine, menu text, rating, open hours and kitchen load.

1. The customer app sends GET /restaurants?lat=..&lng=.. to the API gateway.
2. The gateway authenticates the request and routes it to the Search service.
3. The Search service queries the index with a geo filter (restaurants whose delivery area contains this point), the text match if there is one, and a sort by ETA and relevance. Opening a restaurant calls GET /restaurants/{id}/menu, served from the same place.

Why not query the restaurants table in the main database? Because "contains this point, matches 'paneer', sorted by a score" is exactly what search engines are built for, and because 4k searches a second shouldn't share a database with the money.

2) Customers should be able to place and pay for an order

The customer taps "Place order". We add three things:

• Order service: owns the order and its state machine. It re-prices the cart from the menu and talks to payments.
• Order DB: a relational database (Postgres). Orders are where we need transactions.
• Payment provider: Stripe, Razorpay, Adyen or a bank gateway. A third party, so we draw it dashed.

1. The app sends POST /orders with the item IDs and an Idempotency-Key.
2. The gateway routes it to the Order service, with the customer ID from the JWT.
3. The Order service loads current prices, computes the total, and asks the provider to authorise the amount. Authorising holds the money on the card without taking it.
4. It writes the order with state PLACED and returns the orderId and ETA.

We authorise now and capture later (when the restaurant accepts or when the order is delivered, depending on the business). If the restaurant rejects, we void the hold instead of refunding a charge, which is faster for the customer and cheaper for us.

3) Restaurants should be able to accept or reject an order and mark it ready

The restaurant needs to hear about the order within a second or two, and the rest of the system needs to hear when it's accepted. We add:

• Restaurant app: usually a tablet at the counter.
• Order events: a Kafka topic with one event per state change, keyed by order ID so each order's events stay in order.
• Notification service: consumes order events and decides who to tell and how (push to the app, SMS as a fallback for a restaurant tablet that's offline).

1. When the order is written, an outbox row is written in the same transaction; a relay publishes it to the order events topic.
2. The Notification service consumes order.placed.
3. It pushes "new order" to the restaurant app.
4. The restaurant taps Accept, which reaches the Order service through the gateway as POST /orders/{id}/accept.
5. The Order service moves the order from PLACED to ACCEPTED with a guarded update, and the same outbox path publishes order.accepted.

Later the restaurant taps Ready the same way. If the restaurant doesn't accept within about 3 minutes, the order is cancelled and the hold is voided. We'll make "guarded update" precise in the first deep dive.

4) The system should assign a delivery partner, who picks up and delivers

Now the logistics. To pick a partner we need to know where partners are and when the food will be ready. We add five things:

• Partner app: sends its position every few seconds while online.
• Location service: takes about 125k pings a second and keeps the latest position per partner.
• Geo index: an in-memory store (Redis) of free partners, indexed by area so "who is near this restaurant?" is a few key lookups.
• Prep-time model: predicts when the food will actually be ready.
• Dispatch: consumes accepted orders, decides who and when, and assigns.

1. Every partner app sends POST /partners/location through the gateway to the Location service, which upserts the geo index.
2. Dispatch consumes order.accepted.
3. It asks the prep-time model when this order will be ready.
4. Close to "ready time minus travel time", it reads free partners near the restaurant from the geo index and picks one.
5. It publishes order.assigned.
6. The Notification service pushes the pickup task to the partner app.

The partner then rides to the restaurant, taps Picked up (POST /orders/{id}/pickup), rides to the customer and taps Delivered. Each tap is another guarded state change.

5) All three apps should see the order move in real time

The last requirement is the one people feel. Status changes already flow through order events and Notification. What's missing is the partner's dot moving on the customer's map, and fast updates while the app is open. We add one box:

• Live gateway: a fleet of servers holding one WebSocket per open app.

1. The partner app keeps sending its position to the Location service.
2. The Location service publishes each position on the active order's channel.
3. The Live gateway node holding the customer's socket forwards it to the map.

When the app is closed, there's no socket, so Notification falls back to APNs or FCM for status changes. Nobody needs a map update with the app closed.

044. Deep dives

The board above works for a demo. Now we stress it with the non-functional requirements. For a senior candidate, I expect two or three of these driven by you; for staff, I expect you to pick the ones that matter for this business (timing and partner choice) without being asked.

1) The customer cancels as the restaurant accepts. What does the order end up as?

Three apps can move one order, often in the same second. If two moves both "win", you get a cancelled order that a kitchen is cooking, or a refunded customer whose food arrives anyway.

UPDATE orders SET state = 'ACCEPTED', accepted_at = now()
WHERE id = :id AND state = 'PLACED';
-- 1 row: you won.   0 rows: someone moved it first; re-read and return 409.

2) How do we make sure an order is placed, and charged, exactly once?

Checkout is the worst place to be flaky. The customer taps "Place order", the spinner hangs on a 3G connection, and they tap again. Or the app retries on its own after a timeout. Meanwhile, our call to the payment provider can time out after the provider has already put a hold on the card.

3) When should dispatch send the partner?

This is where food delivery stops looking like Uber. A ride is ready the moment the rider asks. Food isn't ready for 10 to 30 minutes, and we don't know exactly when.

4) Which partner should get which order?

Once an order is due, we need to pick a partner. The geo index gives us free partners near the restaurant; the question is how to choose among them when many orders are due at once.

5) How does search stay fast at dinner time?

At 8 pm, 4k searches a second ask "which open restaurants deliver here, sorted by ETA?". Most of them come from the same few hundred neighbourhoods and ask the same question.

6) How do we show the partner moving on the customer's map without melting the servers?

125k location pings arrive every second, but only the customer, the restaurant and support care about any one partner's position, and only while an order is active.

055. The final design

Here's everything on one board. Each zone is a tier; the numbered steps follow one order from the first search to the partner's dot on the map.

Let's trace one order through it:

1. The customer browses through the API gateway; menus and photos come from the CDN.
2. The Search service filters the index by delivery area, matches the text and ranks by ETA (most home screens are answered from the per-cell cache).
3. The customer orders with an idempotency key. The Order service re-prices the cart and Payments authorises the amount with the provider.
4. The order is written as PLACED with its outbox row in one transaction.
5. The relay publishes it to order events. The restaurant hears about it, accepts, and the guarded update publishes order.accepted.
6. Dispatch consumes the accepted order.
7. It asks the prep-time model when the food will be ready.
8. At the right moment, it reads free partners in nearby cells from the geo index and batch-matches them.
9. It assigns with a guarded write, which publishes order.assigned.
10. Notification consumes every status event.
11. It pushes each change down the open sockets on the Live gateway, or through APNs or FCM when the app is closed.
12. The partner's GPS keeps the geo index fresh and, during the active order, moves the dot on the customer's map.

066. What interviewers look for by level

Mid-level

• Three apps with clear roles and a single order state machine.
• Search on a search index with a geo filter, separate from the order database.
• A geo index for partners and push for status.
• A working end-to-end flow with sensible APIs.

Senior

• Guarded state transitions and the transactional outbox, without being prompted.
• Idempotent checkout, and a second key for the payment provider.
• Dispatch timed by predicted prep time, not at order time.
• Numbers that show which parts are heavy (search and locations, not orders).

Staff+

• Prep time as a distribution with a chosen quantile, and why the business cost picks the quantile.
• Batch matching and order batching, with the trade-off for the first customer.
• Failure handling: restaurant timeouts, partners going dark, Kafka outages, outbox lag.
• How ETA errors and partner wait times feed back into the model.

077. Follow-up questions

What if one partner carries two orders?

Batch orders from the same or neighbouring restaurants that will be ready at similar times and are heading the same way. Score a batch by the extra delay it adds to the first customer, and only batch when that's under a few minutes. In the batch-matching design it's one more option in the cost matrix, so the solver picks it only when it wins.

What if the restaurant doesn't accept?

Put a timer on PLACED, about 2 to 3 minutes. On the first timeout, call the restaurant (an automated IVR call works); on the second, cancel and void the hold. Track acceptance rate per restaurant and lower its ranking, or pause it, if it keeps timing out.

What if two customers in one building write the address differently?

Then you have two drop points for one door, and partners waste minutes hunting. Zomato groups differently written addresses using sentence embeddings and DBSCAN clustering, so "A-4, XYZ Apartments" and "A/4 First Floor, XYZ Apts" land together; it also helps tell public places like stations from homes (Zomato). In the interview, "canonicalise addresses and learn the real drop point from past deliveries" is the line to say.

What if Kafka is down for a minute?

Orders still get placed: the outbox keeps the events in Postgres, and the relay catches up when Kafka returns. Dispatch falls a minute behind, so on recovery it should handle the oldest due orders first, and the prep-time plan for those orders should be re-checked rather than trusted.

What if a kitchen is overwhelmed at 8:30 pm?

Kitchen load is already an input to the prep-time model, so ETAs grow on their own. Go further: when a restaurant's predicted prep time passes a threshold, lower it in search ranking, show a longer ETA, or pause new orders for 10 minutes ("busy mode"). Protecting the promised ETA is worth more than one extra order.

088. How to say it in the interview

When I ask this question, I'm listening for three things: a clean order state machine with safe transitions, the insight that the kitchen sets the clock, and exactly-once ordering and payment.