Optimistic Claim

In a dispatch system — couriers to orders, drivers to rides, technicians to jobs — the candidate data is inherently stale. Locations arrive every few seconds from hundreds of thousands of devices and availability changes continuously. Making that data strongly consistent would cost far more than the decision is worth.

The pattern: rank approximately from stale data, then commit with a conditional write that succeeds only if the resource is still free. If it fails, move to the next candidate immediately rather than retrying.

Why it matters

It resolves the tension between wanting fresh data for a good decision and not being able to afford it. The insight is that you can be approximate about who to ask and must be exact about who was told — and only the second needs consistency.

Locking every candidate during ranking would serialise dispatch across an entire city to protect against a conflict rate of a few percent.

Implementation patterns

• Rank from a stale, cheap read — a geospatial index refreshed asynchronously is fine.
• Commit with a compare-and-set on the resource's authoritative record: assign only if currently unassigned. This is a single-key conditional write and it needs no distributed coordination.
• On failure, advance rather than retry. The resource was taken; retrying the same one is wasted latency in a path measured in tens of milliseconds.
• Enforce offer expiry server-side. A soft reservation held by an unresponsive candidate must be released by the system, because a phone that lost connectivity cannot release its own. Expiry length is a tuned parameter with its own metric: too short and you churn candidates, too long and the job waits while resources idle.
• Make the assignment idempotent so a duplicate acceptance from a retrying client does not double-assign.

Industry example

Food-delivery dispatch at Swiggy's shape has exactly this structure: courier locations and availability are deliberately eventually consistent, while the assignment itself is strongly consistent with a single writer per courier. A courier assigned to two orders is not a display bug — it is a physical failure, a customer complaint and a refund.

Ride-hailing and field-service marketplaces such as Ola and Urban Company use the same shape, and so does seat or slot booking, where the "candidate" is an inventory unit rather than a person.

Failure scenarios

• Pessimistic locking during ranking, which serialises dispatch and destroys throughput for a small conflict rate.
• No conditional check at commit, so two dispatchers assign the same courier and the conflict is discovered physically.
• Client-side expiry, so a disconnected device holds a reservation indefinitely.
• Retrying the failed claim instead of advancing, adding latency to a deadline-sensitive path.
• Stale data so old that the candidate list is mostly invalid, at which point the conflict rate rises and the optimistic assumption stops holding — this is why the staleness must be monitored, not just accepted.

Trade-offs

Optimistic concurrency is correct only while conflicts are rare. As contention rises — a shortage of couriers in a small area during a peak — the failure rate of claims climbs and the system spends its time losing races. At that point the answer is not to switch to locking but to reduce contention: partition the candidate pool, serialise dispatch per geographic cell, or batch assignments so one decision covers several jobs.

The pattern also accepts occasional bad decisions from stale data — offering to a courier who has just gone offline. That cost is a wasted offer and a few tens of milliseconds, which is far cheaper than consistency.

Interview question

"Two dispatchers pick the same courier from a candidate list that was three seconds stale. Both offers are accepted. What in your design prevents a double assignment, and what happens to the second order?"