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 client interface where users browse menus, build baskets, place orders, and track deliveries. Dispatches initial orders, submits order details, and displays real-time courier coordinates. In the demo, notice that status changes from Submitting to Preparing to Delivered.
API Gateway
The single entry point for client requests into the platform. Handles routing, SSL termination, and rate limiting, forwarding customer queries to the OMS and Tracking systems. In the demo, notice that traffic routing arrows passing request details downstream.
Order Management System (OMS)
The orchestrator of the order lifecycle. Enforces the order state machine, tracks order state and coordinates restaurant and courier dispatch states. In the demo, notice that status transitions and coordinate locks during restaurant verification.
ETA Engine
Computes food arrival timelines to manage user expectations. Estimates preparation time and transit time using historic kitchen speeds and active traffic routing details. In the demo, notice that ETA value updates on the customer dashboard.
Restaurant App / Kitchen
The interface for the physical kitchen preparing the meal. Receives orders, permits manual accept/reject decisions, logs preparation progress, and flags when food is ready for pickup. In the demo, notice that status badges changing from Offer to Cooking to Ready.
Dispatch Matcher
Matches physical orders with nearby couriers. Uses prep timing and courier availability, sends delivery offers, records accept/reject responses, and manages retry queues. In the demo, notice that driver matching broadcast cycles and retry status changes.
Courier App / Driver
The mobile application for drivers in the field. Receives delivery offers, tracks GPS coordinates, and allows drivers to log pickup and delivery confirmations. In the demo, notice that status transitions from Offered to Arriving to Picked Up.
Live Tracking Store
Handles high-write GPS coordinate updates. Ingests rapid location streams from courier devices and serves them to customer browsers via WebSockets. In the demo, notice that courier coordinate indicators moving on the map canvas.
Notification Service
Keeps clients informed of order progress asynchronously. Sends push notifications, SMS alerts, or email receipts when order states transition. In the demo, notice that notification triggers sending confirmation messages to the client.
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.