Approximate-Then-Commit

Systems that match resources to demand — couriers to orders, drivers to rides, technicians to jobs, inventory to baskets — need fresh data for a good decision and cannot afford it. Making the candidate data strongly consistent would cost far more than the decision is worth.

The resolution: be approximate about who to ask and exact about who was told. Rank candidates from a stale materialised view, then commit with a conditional write against the authoritative record that succeeds only if the resource is still free.

Why it matters

It separates the expensive guarantee from the expensive path. Selection is high-volume and tolerates staleness; commitment is low-volume and must be exact. Applying one consistency model to both means either paying for precision on the high-volume path or accepting incorrectness on the critical one.

Implementation patterns

• A materialised view updated incrementally from a change stream, with a periodic recomputation to correct drift — because incremental updates miss events, apply them twice, or apply them out of order, and nothing errors: the numbers are simply wrong.
• Commit with a compare-and-set on a single key in the authoritative store. No distributed coordination required.
• On failure, advance to the next candidate rather than retrying. The resource was taken; retrying is wasted latency on a path measured in tens of milliseconds.
• Server-enforced expiry on any soft reservation, because a client that lost connectivity cannot release its own hold.
• Idempotent commitment, so a retrying client does not double-assign.
• Monitor the claim failure rate. It is the direct measure of whether the optimistic assumption still holds, and it rises as contention rises.
• Monitor view staleness and divergence from the source, since the pattern's safety depends on the view being approximately right rather than arbitrarily wrong.

Industry example

Dispatch systems at Ola, Swiggy and Porter have this exact structure: locations and availability arrive from hundreds of thousands of devices and are deliberately eventually consistent, while the assignment itself is strongly consistent with a single writer per resource — because a courier assigned to two orders is not a display bug but a physical failure, a customer complaint and a refund.

Seat, slot and inventory reservation are the same shape with an inventory unit in place of a person.

Failure scenarios

• Pessimistic locking during ranking, which serialises dispatch across a whole region to protect against a few percent conflict rate.
• No conditional check at commit, so two dispatchers assign the same resource 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.
• View drift unmonitored, so the candidate list becomes mostly invalid and the claim failure rate climbs without anyone noticing.

Trade-offs

Optimistic concurrency is correct only while conflicts are rare. As contention rises — a shortage in a small area at peak — the claim failure rate 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 per geographic cell, or batch so one decision covers several jobs. That is a different design and it should be anticipated rather than discovered during a peak.

Interview question

"Two dispatchers select the same courier from a list that was three seconds stale, and both offers are accepted. What prevents a double assignment, what happens to the second order, and at what conflict rate would you redesign this?"