Dispatch and marketplace matching

How ride-hailing, delivery and services marketplaces assign supply to demand: location indexing, candidate selection by ETA, greedy versus batched matching, offers and acceptance timeouts, preventing double assignment, batching orders, and the metrics that matter.

Reading is half of it. See this used in a real interview: walk through Design Uber →

Uber assigns drivers to riders, DoorDash assigns couriers to orders, and services marketplaces assign professionals to jobs. Each runs a dispatch system: a loop that continuously matches moving supply to incoming demand, under time pressure, without ever assigning the same driver twice. It is the heart of every marketplace design question.

The inputs

• Supply: drivers or couriers with live locations (updated every few seconds), status (available, on trip, offline), vehicle type and ratings.
• Demand: requests with pickup and drop-off locations, requested product, time constraints (food ready time, scheduled job).
• Road network for travel times. See routing and shortest paths.

Tracking supply

Location updates arrive at high rates (a million drivers updating every 4 seconds is 250,000 writes per second). Keep current locations in memory, indexed by a geospatial grid (geohash, S2 or H3 cells), partitioned by city or region. Persist the location history asynchronously for analytics and trip records. See geospatial and proximity.

Candidate selection

For a new request:

1. Look up available supply in the surrounding cells, expanding outward until there are enough candidates.
2. Compute ETAs from each candidate to the pickup with the routing engine (straight-line distance is a poor proxy in cities with rivers and one-way streets).
3. Filter by constraints (vehicle type, ratings, capacity).

Greedy versus batched matching

• Greedy: assign each request immediately to the best available candidate (lowest ETA). Simple and fast, but locally optimal choices can be globally bad: taking the nearest driver for rider A may leave rider B with a 15-minute wait.
• Batched: collect requests and available supply for a short window (a few seconds), then solve an assignment problem that minimises total ETA (or maximises a broader objective) across all pairs. Better overall outcomes for a few seconds of delay.

Large marketplaces use batched matching in dense areas and greedy matching where supply is sparse.

Offers and acceptance

Drivers can decline. The flow:

1. Send an offer to the chosen driver with a timeout (10 to 20 seconds).
2. Reserve the driver during the offer so no other request can claim them.
3. On accept, confirm the trip; on decline or timeout, release the driver and try the next candidate.

Track acceptance rates; repeated declines and long timeouts hurt rider wait times.

Never assign twice

Two dispatchers (or two requests in parallel) must not claim the same driver. Options:

• Single writer per region: one dispatch process owns each city's state, serialising decisions. Simple and fast; partition big cities into zones.
• Atomic claim: compare-and-set on the driver's status (available to offered, with an offer id). Losing claimants move to the next candidate.

See distributed locks and leases.

Delivery specifics

Food delivery adds:

• Ready time: dispatch the courier so they arrive when the food is ready, not too early (waiting) or late (cold food).
• Batching orders: one courier carries two orders from nearby restaurants to nearby customers, which increases efficiency at a small delay cost.
• Three-sided timing between customer, restaurant and courier.

See Design DoorDash.

Services marketplaces

For plumbers or cleaners, matching uses skills, ratings, availability calendars and price as well as distance, and offers may go to several providers at once (first to accept wins, with atomic claiming). See Design Contractor Matching.

Balancing supply and demand

When demand exceeds supply, matching alone cannot help; pricing and incentives move supply. See surge and dynamic pricing.

Metrics

• Time to match and pickup ETA (riders).
• Utilisation and idle time between trips (drivers).
• Acceptance and cancellation rates.
• Unfulfilled requests.
• ETA accuracy.

Changes to dispatch logic are evaluated with switchback experiments, because riders and drivers in the same area affect each other. See feature flags and A/B testing.

In the interview

For Design Uber: in-memory location index per region, candidates from nearby cells ranked by routing ETA, batched matching in dense areas, offers with timeouts and atomic driver claims, and per-region single-writer dispatch for consistency.

Checklist

• In-memory geospatial index of supply, partitioned by region.
• Candidates by real ETA, not straight-line distance.
• Greedy or batched assignment depending on density.
• Offers with timeouts; reservation during offers.
• Single writer or atomic claims to prevent double assignment.
• Delivery: ready-time aware dispatch and order batching.
• Matching metrics and switchback experiments.