Food Delivery System Design: Orders, Dispatch & Real-Time Tracking

Food delivery platforms like DoorDash, Uber Eats, and Deliveroo coordinate three parties in real time: customers, restaurants, and drivers. DoorDash alone processes over 2 million orders per day, each requiring sub-second dispatch decisions, continuous location tracking, and precise ETA predictions. Designing a system that keeps all three parties in sync while handling peak dinner rushes is one of the most operationally complex system design problems.

High-Level Architecture#

The system consists of several core domains:

1. Restaurant Discovery Service — Search, browse, and filter restaurants.
2. Menu Management Service — CRUD for menus, items, modifiers, and availability.
3. Order Service — Manages the full order lifecycle from cart to delivery.
4. Dispatch Service — Matches orders to available drivers.
5. Tracking Service — Streams real-time driver location to customers.
6. ETA Service — Predicts preparation time, pickup time, and delivery time.
7. Payment Service — Handles customer charges, restaurant payouts, driver earnings, and tips.
8. Rating Service — Collects ratings for restaurants, drivers, and individual items.
9. Fleet Management Service — Manages driver onboarding, shifts, and incentives.

Restaurant Discovery#

Customers search for food by cuisine, restaurant name, dish, or dietary preference. The system must return relevant results ranked by proximity, rating, delivery time, and promotions.

Search Architecture#

• Elasticsearch powers full-text search across restaurant names, cuisines, and menu items.
• Geospatial filtering limits results to restaurants within delivery radius (typically 5-10 km).
• Ranking signals include: distance, estimated delivery time, customer rating, order volume, promoted placement, and restaurant acceptance rate.

Restaurant Availability#

A restaurant appears in search results only when:

• It is currently open (operating hours check).
• It is accepting orders (not paused due to kitchen overload).
• It is within the customer's delivery zone.
• At least one delivery driver is available in the area (optional soft signal).

Availability status is pushed from restaurants via WebSocket and cached in Redis with short TTLs.

Menu Management#

Restaurants manage their menus through a portal or POS integration.

Data Model#

Restaurant: { id, name, location, cuisine[], operating_hours, avg_prep_time }
MenuCategory: { id, restaurant_id, name, sort_order }
MenuItem: { id, category_id, name, description, price, image_url, available }
Modifier: { id, item_id, name, options[], price_adjustment }

Real-Time Availability#

Items can be marked unavailable (86'd) in real time. When a restaurant runs out of an ingredient, they toggle availability, and the change propagates to the customer app within seconds via:

1. Restaurant updates item status via API.
2. Event published to Kafka topic.
3. Search index and cache updated.
4. Active carts with the item show an "unavailable" warning.

Order Lifecycle#

An order passes through a well-defined state machine:

CART -> PLACED -> ACCEPTED -> PREPARING -> READY_FOR_PICKUP -> DRIVER_EN_ROUTE -> PICKED_UP -> DELIVERING -> DELIVERED

With branches: PLACED -> REJECTED, PLACED -> CANCELLED, PREPARING -> CANCELLED (partial refund).

Order Placement Flow#

1. Cart validation — Verify item availability, calculate totals with modifiers, apply promo codes.
2. Payment authorization — Place a hold on the customer's payment method.
3. Order submission — Persist order and publish event.
4. Restaurant notification — Push notification + tablet alert to the restaurant.
5. Restaurant acceptance — Restaurant confirms and provides estimated prep time (or the system uses historical averages).
6. Dispatch trigger — The dispatch service begins driver matching (often before restaurant accepts, to reduce wait time).

Handling Failures#

• Restaurant rejects — Full refund, suggest alternatives.
• Restaurant timeout — Auto-reject after 5 minutes, refund customer.
• Partial unavailability — Restaurant marks items as unavailable mid-order; customer is notified and can approve a modified order or cancel.

Real-Time Driver Tracking#

Customers expect a live map showing their driver's location. This is one of the highest-throughput components.

Location Ingestion#

Drivers send GPS coordinates every 3-5 seconds via a lightweight protocol:

• WebSocket for persistent connections when the app is foregrounded.
• MQTT as a fallback for low-bandwidth scenarios.

At scale (100,000 active drivers), this is 20,000-30,000 location updates per second.

Architecture#

1. Ingestion layer — Location updates hit a gateway that writes to a Kafka topic.
2. Processing layer — A stream processor (Flink or Kafka Streams) updates the driver's current position in Redis (geospatial index).
3. Delivery layer — Customer apps subscribe to their driver's location via WebSocket. The server pushes updates every 3-5 seconds.

Geo-Hashing for Proximity#

Driver positions are stored in Redis using GEOADD. When dispatch needs nearby drivers, it queries GEORADIUS to find all drivers within a given radius of the restaurant — returning results in under 5 milliseconds.

ETA Estimation#

Accurate ETAs are critical for customer satisfaction. The total ETA has three components:

1. Preparation Time#

Predicted using ML models trained on:

• Restaurant's historical prep times by order size and time of day.
• Current kitchen load (number of active orders).
• Specific items ordered (a salad is faster than a pizza).

2. Driver-to-Restaurant Time#

Estimated using:

• Road network routing (Google Maps API, OSRM, or internal routing engine).
• Real-time traffic data.
• Driver's current location and heading.

3. Restaurant-to-Customer Time#

Same routing approach, from restaurant to customer delivery address. Accounts for multi-stop deliveries if the driver is batching orders.

Continuous Recalculation#

ETAs are recalculated every 30-60 seconds as conditions change (traffic, kitchen delays, driver detours). Customers see a live countdown that adjusts smoothly to avoid jarring jumps.

Dispatch & Matching Algorithm#

Dispatch is the brain of the system. It matches orders to drivers, optimizing for speed, cost, and fairness.

Matching Strategies#

• Nearest available driver — Simple but suboptimal. Ignores driver heading and upcoming order completion.
• Batching — Group multiple orders going in the same direction for a single driver. Reduces cost but increases delivery time for the second order.
• Predictive dispatch — Start routing a driver toward a restaurant before the food is ready, using predicted prep time. Minimizes idle wait at the restaurant.

Optimization Objective#

The dispatch engine solves a constrained optimization problem:

• Minimize: Total delivery time across all pending orders.
• Subject to: Driver capacity (1-2 active orders), maximum acceptable delivery time, fair distribution of orders across drivers.

In practice, this runs as a batch optimization every 10-30 seconds, considering all unassigned orders and all available drivers simultaneously — not just matching one order at a time.

Driver Assignment Flow#

1. Order enters the dispatch queue.
2. Dispatch engine identifies candidate drivers (nearby, available, heading in the right direction).
3. Best match is computed and an offer is sent to the driver.
4. Driver has 30-60 seconds to accept.
5. If declined or timed out, the order is re-offered to the next best driver.
6. After 3 failed attempts, the system widens the search radius.

Payment & Splitting#

Food delivery payments involve multiple parties and complex splits.

Payment Breakdown#

• Subtotal — Item prices plus modifiers.
• Delivery fee — Variable based on distance and demand.
• Service fee — Platform fee (typically 10-15% of subtotal).
• Tip — Customer-set, goes entirely to the driver.
• Promotions — Coupons, free delivery, discounts absorbed by the platform or restaurant.

Revenue Split#

Restaurant payout = subtotal - platform_commission (15-30%)
Driver payout     = base_pay + distance_bonus + tip + peak_bonus
Platform revenue  = delivery_fee + service_fee + commission - promotions

Payment Flow#

1. Authorize at order placement.
2. Capture after delivery confirmation.
3. Adjust if items were removed or substituted.
4. Tip adjustment — Customers can modify tip for up to 2 hours post-delivery.
5. Batch payouts to restaurants (daily/weekly) and drivers (weekly or instant via earned wage access).

Surge Pricing#

During peak demand (Friday dinner, rainy days, game nights), the platform implements surge pricing to balance supply and demand.

Surge Mechanism#

1. Demand signal — Order volume in a geo-zone exceeds available driver supply.
2. Surge multiplier — Delivery fee is multiplied (1.2x to 2.5x) based on the supply-demand ratio.
3. Driver incentives — Higher per-delivery pay attracts more drivers to the zone.
4. Customer transparency — Surge pricing is displayed before order placement. Customers can opt to wait for prices to normalize.

Geo-Zone Granularity#

The city is divided into hexagonal zones (H3 indexing). Each zone has independent supply-demand metrics, enabling localized surge pricing rather than city-wide adjustments.

Ratings System#

Three-way ratings maintain marketplace quality:

• Customer rates restaurant — Food quality, accuracy, packaging (1-5 stars).
• Customer rates driver — Professionalism, speed, communication (1-5 stars).
• Restaurant rates driver — Punctuality, handling.
• Driver rates customer — Accessibility, responsiveness.

Impact of Ratings#

• Restaurants below 4.0 stars are deprioritized in search rankings.
• Drivers below 4.5 stars receive fewer high-value order offers.
• Customers with low ratings (rude, unreachable) may see longer wait times.

Ratings are aggregated over a rolling 90-day window, weighted toward recent orders.

Driver Fleet Management#

A healthy driver supply is critical. The fleet management system handles:

Shift Planning#

• Scheduled shifts — Drivers sign up for time blocks, guaranteeing minimum earnings.
• Open mode — Drivers go online anytime but without guaranteed minimums.
• Demand forecasting — ML models predict order volume by zone and time, determining how many drivers are needed.

Incentive Programs#

• Peak bonuses — Extra pay during predicted high-demand windows.
• Quest bonuses — "Complete 20 deliveries this weekend for an extra $50."
• Referral bonuses — Existing drivers recruit new ones.
• Streak bonuses — Accept 3 consecutive orders without declining for a bonus.

Driver Lifecycle#

APPLIED -> BACKGROUND_CHECK -> ONBOARDED -> ACTIVE -> DEACTIVATED

The system tracks driver documents (license, insurance, vehicle registration) and flags expirations for re-verification.

Key Design Trade-offs#

Conclusion#

A food delivery system is a real-time coordination platform that must balance the needs of three distinct user types while handling extreme demand variability. The dispatch algorithm is the competitive differentiator — even small improvements in matching efficiency compound into millions of dollars in savings and minutes off delivery times.

The key architectural insight is event-driven communication between loosely coupled services. The order service publishes events; dispatch, tracking, payments, and notifications all react independently. This enables each service to scale, fail, and evolve on its own timeline.

---

Ready to practice system design problems like this with AI-powered feedback? Try it at codelit.io.

This is article #202 in the Codelit system design series.