Food delivery and fast local delivery (iFood/DoorDash/Gopuff)

01 · CONTEXT AND REQUIREMENTS

Two questions in one: what can I deliver here, and who takes it

Food delivery and fast local delivery look like a single problem, but they hide two questions. The first is about the catalog: which items can be delivered to that location right now. The second is about logistics: after the order, which courier takes it and when should they leave. This case uses an interview-prep source, about a convenience company, for the first question, and an iFood publication for the second.

The convenience source describes fast delivery from 500+ micro-distribution centers. The core requirement is to query the availability of items deliverable within one hour, by location, summing the stock of nearby centers. The query must be fast, under one hundred milliseconds, and the order must be strongly consistent: two customers cannot buy the same physical product. The source itself assumes orders on the order of tens of millions per day.

The source leaves courier routing out of scope. That is why the second half of the case looks at the iFood publication, which describes how the order, the courier, and kitchen time enter the dispatch decision.

02 · AVAILABILITY

Which centers reach the customer in time

1. The app sends the customer's location to the availability service, along with the items they are looking for.

2. The availability service asks the nearby-centers service which centers reach the customer; it filters candidates and queries the external travel-time service.

3. With the centers in hand, the service looks at the availability cache first.

4. With no answer in the cache, the query falls to the stock replicas, which sum the stock of the centers; the result goes back to the cache.

5. The leader database is reserved for order writes; availability reads go to the replicas.

Measuring only straight-line distance is misleading: a center can be close in distance and far in travel time, because of a river or a border, and the simple calculation also ignores traffic and road conditions. On the other hand, asking the external service for the travel time of every center generates too many queries, since most would never arrive in time.

03 · READ SCALE

Many queries, few purchases

The source starts from the volume of orders per day to estimate about 20 thousand availability queries per second. For this load, it points to cache aggressive with a short TTL. The trade-off is that the order service must expire the affected entries when it writes to the stock.

The second way out is to combine particionamento and read replicas. The source groups the centers by region, using the first digits of the ZIP code, so that queries land on few partitions. Availability reads can go to the replicas because they tolerate slight inconsistency; order transactions go to the leader.

04 · ORDER AND CONSISTENCY

Not selling the same item twice

1. The app sends the order with several items to the order service.

2. The service opens a single transaction on the leader database: it checks the stock, records the order, and updates the stock, all together.

3. If any item is no longer available, the whole order fails.

4. After writing to the stock, the order service expires the cache entries that became stale.

5. Availability queries continue to be served by the read replicas.

To avoid selling the same stock to two users, some form of lock is needed. With two databases, one for orders and another for stock, the source recalls the failure modes: the service crashing between creating the order and decrementing the stock, and two orders with overlapping stock. As an alternative, it describes a single transaction in one database, which records the order and updates the stock.

05 · COURIER DISPATCH

Nearest is not enough

1. The customer places the order and the order service passes the information to the restaurant.

2. The restaurant has about 8 minutes to confirm; without confirmation, the order is canceled automatically.

3. Prediction models report the kitchen time, which helps decide when to send the courier to the restaurant.

4. The courier app sends a constant stream of data; dispatch needs to know the fleet, the positions, and who can pick up an order.

5. The optimizer tests route hypotheses between orders and couriers, seeking to minimize delays; it batches orders only if none of them is delayed.

6. Monitoring tracks orders and delays live; a delayed order triggers an automatic incident.

The decision is made minute by minute, at a scale far larger than that of a single courier. The goal is to find the best courier for each order, so that they arrive at the restaurant on time and then at the customer. Orders arise all the time, spread across the city.

06 · SYNTHESIS

Different guarantees for different paths

Availability, order, and dispatch call for different guarantees, and the design improves when each path gets its own. The availability read can use cache and replicas. The order requires strong consistency and, in the sources, goes to a single transaction. Dispatch works with information that changes all the time and with promised-deadline rules; in the didactic design, orders and positions reach it through an event stream.