Design Driver Matching/Tracking Service - Follow-up questions - Intuition First, Need more How

Here is solutions for Design DoorDash.

There is 2 core components:

  • Search Service

  • Matching Service

Main point:

  • Collecing driver location: for real-time driver location tracking is an excellent choice that enables efficient proximity-based driver matching.

  • Matching Service: ensure 1 driver - 1 order at the same time, prevent driver spam orders.

  • Order assigning logic: calculate metrics to decide assign order for the driver or not.

  • Asynchronus Payment Processing: because it is a high-throuput system.

  • Order/outbox and idempotency: to make sure order consistency.

  • Doordash:

doordash

1. Patterns for Design for Matching Service

  1. Driver assignment and “optimal” routing: pull N nearby drivers from Redis GEO, then score them with a simple cost function using live ETAs from a routing service -> ETA = pickup_eta + delivery_eta + detour_penalty + batching_penalty.

  2. Single-writer and race-free matching: using Lua script -> check driver is idle → set active_offer=orderId with TTL → return OK, prevent double-assign and spam.

  3. Driver state-machine: keep a Redis hash per driver with state {offline, idle, en_route_pickup, at_pickup, delivering, paused} plus a heartbeat TTL. -> Only the matching service changes state.

  4. Prevent driver spam:: enforce one active offer per driver via the Redis key with TTL. Add a cooldown (e.g., 60–120s) before re-offering to the same driver. Track per-order tried_drivers to avoid repeats.

  5. Asynchronous payment flow: On place order: create a PaymentIntent/authorize (idempotency key, async via payments worker/outbox).

  • Match immediately, cancel if payment fails (Most common)

    0s User requests ride

1s Driver accepts

2s Payment authorization starts

5s Payment fails

6s Cancel ride

7s Driver becomes available again

  1. Order/outbox and idempotency: make sure 1 order_id is match by 1 driver at the same time -> have state machine.

  2. Auto re-dispatch when drivers offline: if a driver accepts then drops offline, set a short grace (e.g., 60–120s). If they don’t recover, auto re-dispatch. If payment was captured, void/refund and reassign. If restaurant cancels an item, split into child orders per restaurant and do partial refunds.

  3. Retry strategy for ignored requests: collect candidate poll first -> advance index, widen radius, or increase offer (surge) after thresholds.

  4. Track driver location: track offline driver and exclude it.

  5. Peak hours: handle matching in peak hours -> wider radius.

July 22, 2026