Food Delivery Fulfillment Lifecycle
Follow a food delivery order through checkout, restaurant acceptance, courier dispatch, pickup, live tracking, and customer notification.
Continue with the guided workspace
Use the paired workspace to connect this guide's mental model with live component state, visible signals, and the outcome each step or scenario is meant to prove.
Follow the lifecycle of a food delivery order through a three-sided marketplace. Inspect states across OMS, Dispatch, Restaurant, and Courier apps, and see how system rejections or delays are managed.
Mental Model
Food delivery is a complex physical coordination problem operating as a three-sided marketplace (Customers, Restaurants, and Couriers).
Fulfillment is not just a database write; it is a distributed state machine:
- The Customer requests a basket.
- The Order Management System (OMS) coordinates authorization and kitchen acceptance.
- The Restaurant cooks the food according to a preparation window.
- The Dispatch Matcher searches for nearby Couriers to ensure the driver arrives exactly when the food is ready.
- Live Tracking and Notification systems keep all parties synchronized as the physical delivery completes.
Components and Why They Exist
Customer App
The customer app is the client interface where users browse menus, build baskets, place orders, and track deliveries. It dispatches initial orders, submits basket details, and displays real-time courier coordinates as the customer status badge transitions from Submitting to Preparing to Delivered.
API Gateway
The API gateway is the single entry point for client requests into the platform. It handles request routing, TLS termination, and rate limiting before forwarding customer queries to the OMS and Tracking systems, with traffic routing arrows carrying request particles downstream.
Order Management System (OMS)
The Order Management System (OMS) orchestrates the end-to-end order lifecycle. It enforces the order state machine, records state transitions, and coordinates restaurant preparation with courier dispatch as confirmation events arrive from both sides.
ETA Engine
The ETA engine computes food arrival timelines to set accurate customer expectations and time courier dispatch. It estimates preparation time and transit time using historical kitchen speeds and active traffic conditions, updating the live ETA metric on the customer panel as fulfillment progresses.
Restaurant App / Kitchen
The restaurant app is the tablet interface for the physical kitchen preparing the meal. It receives incoming orders, permits manual accept or reject decisions, logs preparation progress, and flags when food is ready for pickup, shifting the kitchen status badge from Offer to Cooking to Ready.
Dispatch Matcher
The dispatch matcher pairs physical orders with nearby couriers so drivers arrive as meals finish cooking. It evaluates prep timing and courier availability, sends delivery offers, records accept or reject responses, and manages retry queues whenever an initial driver offer is declined.
Courier App / Driver
The courier app is the mobile application used by drivers in the field. It receives delivery offers, streams GPS coordinates, and lets drivers log pickup and drop-off confirmations as the courier card state moves from Offered to Arriving to Picked Up.
Live Tracking Store
The live tracking store absorbs high-write GPS coordinate updates from active couriers. It ingests location streams from driver devices and serves live position updates to customer clients as the driver moves toward the restaurant and final drop-off address.
Notification Service
The notification service keeps customers informed of order progress asynchronously. It sends push notifications, SMS alerts, or email updates whenever order states transition or delays occur, delivering confirmation and recovery alerts to the customer card.
Edge Cases and Misconceptions
- Courier rejections cascade delay: When a courier rejects a delivery offer (which they are free to do as independent contractors), the dispatch engine must wait for the offer timer to expire (e.g. 30 seconds) before offering it to the next driver. If three drivers reject in sequence, the food sits on the restaurant counter for 1.5 minutes, increasing food degradation.
- GPS location lag: Live tracking does not show continuous real-time movement. Courier location is updated via periodic HTTP POST telemetry (e.g., every 5-10 seconds) to conserve battery. The client app interpolates the dots between points to make the driver appear to move smoothly.
- OMS and restaurant-app sync failure: A major failure mode is POS integration disconnects. If the restaurant app loses connectivity, the kitchen cannot receive the order. The OMS must detect this connection loss and cancel the order early, rather than letting the customer wait indefinitely.
- Forward recovery after physical work: If a courier rejects after the kitchen has started, OMS cannot undo cooking. Dispatch keeps searching and Notification Service communicates the delayed ETA or next action.
Frequently Asked Questions
The questions above focus on the fulfillment tradeoffs represented by the paired visualization.
Common Questions
How does the Dispatch Matcher select the optimal courier for an order?
The Dispatch Matcher uses preparation timing, courier proximity, and explicit offer acceptance. In this demo, it sends an offer to a candidate courier and waits for an accept or reject response before treating the courier as assigned; a production matcher may add geographic indexes or batch optimization, but those algorithms are not modeled here.
What happens when a restaurant accepts an order but no couriers are available?
This is the driver scarcity state (Ready Without Courier). The restaurant kitchen proceeds to cook the food to honor the freshness contract, while the Dispatch system places the order in a retry queue to continuously broadcast offers with increased payouts. If no courier is matched within a threshold, the order is canceled, and the platform compensates the restaurant for the wasted food.
Why can fulfillment recover without undoing physical work?
The demo models forward recovery across OMS, restaurant, dispatch, and notifications rather than an atomic transaction. If a restaurant rejects or a courier declines, OMS records the new state and dispatch retries or notifies the customer; physical work such as cooking cannot be rolled back.
Why is ETA calculation hard after the kitchen accepts an order?
The ETA depends on two physical processes that can drift independently: food preparation and courier travel. A good ETA engine must combine kitchen speed, courier proximity, traffic, pickup wait time, and retry delays when drivers reject offers.