Food Delivery System Design Interview Guide: Dispatch, Geospatial Search, ETAs, and Order State

A strong food delivery system design interview answer separates three kinds of truth: durable order state, fast-changing marketplace state, and predictive estimates. Keep orders and legal transitions in a transactional database, maintain nearby courier and restaurant availability in geo-partitioned hot indexes, and recompute dispatch and ETAs as the marketplace changes.

Food delivery system: a three-sided marketplace that lets customers discover deliverable restaurants, creates durable orders, coordinates merchant preparation with courier assignment, tracks fulfillment, and recovers from partial failure. The hardest part is aligning several timelines without losing order correctness.

This guide is for software engineers preparing for a backend or distributed-systems round. Practice the trade-offs with PracHub system design interview questions; the question bank is practice material, not a prediction of an exact interview prompt.

The scope runs from restaurant discovery through delivery completion. Payment ledgers, notification fan-out, recommendation training, and street-level routing stay outside the core design.

Architecture focus: durable order transitions coordinate faster, approximate discovery, dispatch, tracking, and ETA services.

Food delivery system design interview: the quick answer

Start with a regional architecture. A customer search request uses a geospatial index to find restaurants whose delivery polygons cover the address, then a search service ranks only open and serviceable candidates. Checkout creates one authoritative order_id through an idempotent command and stores an initial order state plus an outbox event in the same transaction.

Merchant, dispatch, courier, payment, and notification services react to ordered events. The dispatch service retrieves nearby available couriers, estimates merchant-ready time, pickup travel, delivery travel, and acceptance likelihood, then atomically reserves one courier for one offer. A workflow coordinator advances valid order transitions, times out abandoned steps, and compensates when payment, inventory, merchant acceptance, or delivery fails.

Clarify requirements, scale, and invariants first

Ask about scheduled orders, stacked deliveries, substitutions, live location, delivery polygons, and courier capacity.

Use explicit assumptions. One interview model could be 5 million orders per day, 250,000 online couriers, location pings every 5 seconds, and a 2-second dispatch target. These numbers only justify partitions, write volume, retention, and latency budgets.

State these invariants before drawing services:

• Every client retry maps to one logical order, payment attempt, assignment, or status change.
• One order has at most one active courier assignment, and one courier cannot exceed current capacity.
• Order state moves only through allowed transitions with a monotonic version.
• A stale GPS ping or delayed event cannot overwrite newer state.
• Terminal orders remain reconstructable from durable data and an audit trail.

Build around one authoritative order path

Use an API gateway in front of Customer, Merchant, and Courier APIs. Separate Catalog and Search from Order, Dispatch, ETA, Tracking, Payment, and Notification services. A transactional Orders store is the fulfillment source of truth; a partitioned event stream distributes committed changes.

Menus, hours, service areas, and availability feed a search index. Courier location gateways publish mobile pings to a stream. Consumers update courier_id -> latest position and geo_cell -> available couriers hot indexes, while colder history goes to analytical storage.

The customer read model combines order state, merchant updates, assignment, last safe courier location, and ETA. It can be eventually consistent because the durable order record decides legal state.

Model order state explicitly

A useful schema includes Order(order_id, merchant_id, status, version, total), OrderItem, PaymentAttempt, CourierAssignment, and OrderEvent(order_id, sequence, type, payload). Keep predictions such as promised_at separate from legal state.

One state path is CREATED -> PAYMENT_AUTHORIZED -> MERCHANT_CONFIRMED -> PREPARING -> READY_FOR_PICKUP -> COURIER_PICKED_UP -> DELIVERED. Alternate paths include PAYMENT_FAILED, MERCHANT_REJECTED, CUSTOMER_CANCELED, DELIVERY_FAILED, and REFUND_PENDING.

Each command supplies expected_version and an idempotency key. The Orders service validates the transition, conditionally updates state, and writes an outbox row in one transaction. AWS's transactional-outbox guidance explains why: an unrelated database write and message send can leave either side missing.

Partition order events by order_id. Apache Kafka documents that same-key events can share a partition and be consumed in that partition's write order. Consumers still deduplicate by event_id and reject any sequence older than the highest applied sequence.

Workflow focus: an ordered state machine controls fulfillment while geospatial and ETA services provide replaceable decision inputs.

Use geospatial search as candidate generation

Do not call an expensive road-routing service for every restaurant or courier. First reduce the search space with a geographic index; route only the surviving candidates.

H3's gridDisk returns cells within k grid steps of an origin. PostGIS ST_DWithin can use spatial indexes to filter points within a distance, and its geography form accepts meters. Use coarse cell lookup first, then exact polygon or route validation.

For restaurant discovery, require the delivery address to fall inside the merchant's active service area. For courier dispatch, expand from the pickup cell until the candidate pool is large enough or a maximum radius is reached. Drop couriers whose last accepted ping is stale or whose capacity is already reserved.

Dispatch is matching, not nearest-neighbor lookup

The nearest idle courier is not always the best courier. DoorDash's public engineering description separates dispatch into candidate offers, predictions, and an optimization layer. It considers geography, merchant-ready time, travel time, acceptance likelihood, batching, and the choice to dispatch now or wait.

Use this interview-friendly shape:

1. Generate nearby, available courier candidates and compatible order batches.
2. Predict courier-to-merchant time, merchant-ready time, pickup overhead, drop-off travel, and acceptance probability.
3. Score lateness risk, courier utilization, detour, capacity, fairness constraints, and uncertainty.
4. Select an assignment, then atomically claim the courier and order with a short lease.
5. Send an offer; on decline or timeout, release the lease and try the next plan.

Begin with a weighted score or greedy matcher. Discuss bipartite or mixed-integer optimization only after the basic flow works and global supply-demand trade-offs justify it.

Treat ETA as a decomposition that keeps changing

Customer ETA is not just road travel time. A useful decomposition is:

ETA = merchant queue + remaining prep + courier-to-merchant + pickup overhead + merchant-to-customer + drop-off overhead

At checkout, several terms are estimates. Merchant confirmation improves prep time; assignment and pickup make live GPS and traffic more important. Recompute at state changes, route deviation, or bounded intervals instead of fanning out every raw ping.

Google Maps Routes API documents separate route and route-matrix methods, traffic-aware durations, and a quality-versus-latency choice. A dispatch system can use a cheap approximation for a large candidate set, a route matrix for the shortlist, and a detailed route for the selected courier.

Version ETA updates and include computed_at, input freshness, and a range. If routing fails, use cached cell-to-cell travel times plus historical merchant prep and label the estimate degraded. Measure p50 and p90 absolute error by city and fulfillment stage.

Design retries and compensation for partial failure

Assume at-least-once delivery. Idempotency makes repeated commands safe; ordered versions make stale events harmless; reconciliation repairs missing or contradictory outcomes.

Use a workflow coordinator or saga for multi-service steps. AWS's guidance makes compensation, eventual consistency, idempotency, and observability explicit costs. A merchant rejection can void an authorization and cancel dispatch; a courier timeout can reopen assignment; an unknown payment result remains PAYMENT_PENDING until confirmation or reconciliation.

Retry only transient failures with timeouts, capped exponential backoff, jitter, and a retry budget. Jitter prevents synchronized retries from forming another burst. Send exhausted work to an exception queue with an operator-visible reason.

For customer updates, link status events to the notification system design guide rather than rebuilding channel preferences and delivery guarantees inside the order service.

Scale by region and degrade deliberately

Partition hot paths by metro because discovery, dispatch, courier supply, and most orders are local. Within a region, shard events by order_id and geo indexes by cell. Split dense cells and isolate hot merchants.

Route a customer order to one home region and record region ownership. During a partition, avoid active-active assignment of the same courier across two regions. Prefer a single writer for courier availability, a handoff protocol with leases, and a conservative unavailable state while ownership is uncertain.

Degrade by preserving correctness first. If recommendations fail, show popular deliverable restaurants. If precise routing fails, show a wider ETA range. If live tracking lags, display the last safe update time. If dispatch is saturated, stop accepting impossible promises or expand delivery windows instead of creating orders the marketplace cannot fulfill.

Monitor transition conflicts, event lag, stale locations, offer acceptance, time-to-assign, double-claim attempts, ETA error, cancellations, and reconciliation backlog. Trace with order_id, assignment_id, and event_id.

A 45-minute interview walkthrough

Spend 5 minutes clarifying scope, scale, batching, and correctness. Use 5 minutes for APIs, data, states, and invariants, then about 10 minutes for the architecture.

Use 10 minutes for the deepest path: geospatial candidate generation, dispatch scoring, and atomic assignment. Spend another 8 minutes on ETA updates, outbox events, idempotency, retries, and compensation. Reserve the final 7 minutes for regional failure, graceful degradation, metrics, and a concise recap.

The complete PracHub system design prep guide can help you practice this requirement-to-trade-off rhythm across other prompts.

Practice with related PracHub questions

These questions isolate the hardest subproblems without claiming that your interviewer will ask the same prompt.

Frequently asked questions

What is the hardest part of a food delivery system design interview?

The hardest part is coordinating merchant preparation, courier supply, travel time, payment, and customer expectations while keeping order state correct. A strong answer separates durable transitions from approximate predictions, then explains how idempotency, ordered events, conditional assignments, timeouts, and reconciliation handle partial failure.

Should food delivery dispatch always choose the nearest courier?

No. Nearest distance is only a candidate-generation signal. A better decision also considers merchant-ready time, road travel, courier capacity, existing route, acceptance likelihood, batching detour, lateness risk, and marketplace supply. Start with a weighted scorer, then discuss global optimization if scale and trade-offs justify it.

Which geospatial index should I choose for food delivery?

Use a hierarchical cell grid such as H3 for fast regional partitioning and neighbor expansion, PostGIS for durable polygon and exact-distance queries, and an in-memory geo index for fresh courier positions. Many designs combine them: coarse lookup first, exact validation second, routing only for a shortlist.

How do you prevent duplicate courier assignments?

Keep one authoritative assignment record and claim it with a conditional write, monotonic version, or serialized regional owner. Give provisional offers a short lease, make the command idempotent, and release only when the stored assignment ID matches. Cross-region handoff should conservatively prevent two writers from owning one courier.

How should the system handle out-of-order status updates?

Partition fulfillment events by order_id, attach a monotonic sequence or version, and make each consumer remember the highest applied version. Reject stale transitions, deduplicate repeated event_id values, and reconcile gaps against the authoritative order record. Device timestamps alone are insufficient because clocks and networks can disagree.

Final takeaway

The best food delivery system design interview answer is not a catalog of microservices. It is a defensible separation of concerns: transactional order truth, geo-indexed marketplace state, predictive dispatch and ETA inputs, ordered events, and explicit recovery paths.

Start with one regional lifecycle, prove assignment and transition invariants, then add geo-sharding, asynchronous projections, controlled retries, and graceful degradation. Use the five linked questions to pressure-test each subsystem.

Sources and Further Reading

• DoorDash Engineering: Using ML and Optimization to Solve DoorDash's Dispatch Problem
• H3 documentation
• H3 grid traversal functions
• PostGIS ST_DWithin
• Google Maps Routes API
• Apache Kafka documentation
• AWS Prescriptive Guidance: Transactional outbox pattern
• AWS Prescriptive Guidance: Saga orchestration pattern
• AWS Architecture Blog: Exponential Backoff and Jitter
• Stripe: Idempotent requests

Research note: This guide was checked on September 1, 2026. The numeric scale and latency values are interview assumptions; production requirements vary by market and product.