Commitment Read

A client cache makes an interface feel instant, and it introduces staleness. The question is not whether staleness is acceptable but where it is not — and the answer is at the point where a stale value would permit an action that cannot be undone.

The commitment is never served from cache. The stock reservation, the price charged, the balance checked before a transfer, the entitlement verified before access.

Why it matters

The separation is what makes aggressive caching safe. Without it, the choice is between a slow interface and an incorrect one; with it, everything except a small number of reads can be cached hard — and the expensive guarantee is needed only on the cheapest path, since commitment volume is a small fraction of browse volume.

Implementation patterns

• Classify reads by consequence: display, decision-support, and commitment. Only the last requires authority.
• Stale-while-revalidate for the rest, with a per-data-type tolerance rather than one global setting.
• Design the failure path. When the cached value turns out wrong at commitment, the response must be a designed experience — substitute, remove and re-price, offer an alternative — rather than a generic error at the payment step, which is the worst possible moment for one.
• Invalidate on the events that change everything: a completed order, an account switch, and — for a location-scoped product — a change of location, which is the invalidation most often missed and which invalidates almost the entire cache.
• Bound the cache with eviction, since an unbounded local store exhausts device storage.
• Define offline behaviour: a cached view with a clear indicator for browsing, and a refusal rather than a queued action for anything committing, since a queued commitment the user believes succeeded is the worst outcome.

Industry example

Quick-commerce platforms such as Zepto and Swiggy show inventory that changes continuously while promising an instant interface. The reservation at checkout is strongly consistent and single-writer; everything upstream of it is a cached projection — and that split is the whole design rather than an optimisation within it.

The same shape governs seat booking, ticketing, and any product where a displayed availability precedes a commitment.

Failure scenarios

• Committing from cache, producing overselling or an incorrect charge.
• A generic error when the cached value was wrong, at the payment step.
• Location or account change not invalidating, so a user sees another context's data.
• Unbounded client storage.
• A queued offline commitment the user believes completed.

Trade-offs

The authoritative read at commitment is slower, and it introduces a dependency at the moment the user is most committed — so its availability requirement is higher than anything else in the path.

That is the correct place to concentrate reliability investment, precisely because the volume is low: it is the cheapest possible place to be strict, and the most expensive place to be wrong.

Interview question

"Your app shows an item as available, the user taps buy, and it is gone. Walk me through what your system does in the next two seconds, and tell me which read was cached and which was not."