Design a Food Delivery API
You'll learn to
- -Design a multi-actor state machine spanning customer, restaurant, and driver, each with different visibility into the same order
- -Combine geospatial querying, real-time location tracking, and REST resource modeling in one coherent system
A food delivery API is a genuinely multi-sided problem - three distinct actors (customer, restaurant, driver) interact with the same underlying order, each needing a different view and different real-time guarantees, which makes this prompt a strong test of resource modeling under real complexity rather than any single isolated technique.
Step 1-2: Three Actors, One Order Resource
The `Order` resource is shared across all three actors, but each needs a different slice of it: the customer cares about status and estimated arrival; the restaurant cares about the items to prepare and a ready-for-pickup signal; the driver cares about pickup and drop-off locations and navigation. This is a natural candidate for the BFF pattern from the systems module - three different views of the same underlying resource, tailored per actor, rather than one shared response trying to serve all three equally well.
Step 3: A Multi-Actor Order State Machine
- -POST /v1/orders - customer places an order
- -GET /v1/orders/{id} - fetch an order (response shaped per actor via the BFF layer)
- -POST /v1/orders/{id}/transitions - the one endpoint every status change goes through, e.g. {"transition": "ready_for_pickup"}
- -GET /v1/restaurants/{id}/orders?status=preparing - a restaurant's queue of active orders
{
"id": "ord_501",
"status": "out_for_delivery",
"status_history": [
{"status": "placed", "at": "..."},
{"status": "confirmed_by_restaurant", "at": "..."},
{"status": "preparing", "at": "..."},
{"status": "ready_for_pickup", "at": "..."},
{"status": "picked_up", "at": "..."},
{"status": "out_for_delivery", "at": "..."}
]
}POST /v1/orders/ord_501/transitions
Authorization: Bearer <driver_token>
{"transition": "picked_up"}
HTTP/1.1 200 OK
{"id": "ord_501", "status": "picked_up"}
HTTP/1.1 403 Forbidden
{"error": "Only the assigned driver may transition this order to picked_up"}Each transition is triggered by a different actor - the restaurant confirms and marks ready, the driver marks picked up and delivered - which needs authorization scoped per transition (only the assigned driver can mark `picked_up`, only the restaurant can mark `ready_for_pickup`), the same field/action-level authorization discipline from the GraphQL security chapter, applied here to REST state transitions instead of GraphQL fields. Note this is one endpoint (POST .../transitions) rather than a separate endpoint per status - the state machine's legal-transition table (echoing the idempotency-and-state-machines pattern from LLD Fundamentals) is what actually decides whether a given transition is allowed, not which URL was called.
Step 4: Geospatial Queries
GET /restaurants/nearby?lat=40.7128&lng=-74.0060&radius_km=5&cuisine=italian"Restaurants near me" is a specialized filtering problem - it needs a spatial index (like a geohash or R-tree, conceptually similar to the indexing strategy discussion from the file-upload and search chapters) rather than a plain equality or range filter, since "distance from this point" isn't something a standard B-tree index can answer efficiently at scale.
Real-Time Driver Location
service TrackingService {
rpc WatchDriverLocation (WatchRequest) returns (stream LocationUpdate);
}This is server streaming from the gRPC modules, applied directly - the customer opens a stream once and receives a continuous flow of location updates as the driver moves, rather than polling a REST endpoint repeatedly (the same live-feed reasoning from the GraphQL subscriptions chapter, here expressed as gRPC server streaming instead).
The strongest answers to this prompt explicitly name which earlier technique each piece of the design reuses - geospatial search resembles the search/indexing chapters, the state machine mirrors the idempotent-transition discipline from the schema-design track, live tracking is server streaming - rather than treating this as an unrelated, novel problem from scratch.
Interview Signal is part of Pro
See a real weak answer next to a real strong one for this exact topic.
Quiz is part of Pro
Test what you just read with a short quiz, and bank the XP.
Design a Food Delivery API in the API Design Lab's Full System Design act.