A quick-commerce app must feel instant while showing inventory that changes constantly. What caching strategy on the client?

The strategy

Stale-while-revalidate, with a per-data-type staleness tolerance and a hard correctness boundary at commitment.

• Show the cached value immediately, so the interface is instant.
• Revalidate in the background and update if it changed.
• The tolerance differs by data type: a category listing can be minutes stale; the availability shown when an item is added to the basket should be seconds; the reservation at checkout must be a live authoritative call.

The boundary that must not be crossed

The commitment is never served from cache. The stock reservation, the price charged and the order submission read the authoritative source — because a stale value that permits an action that cannot be undone is the failure mode that matters, and everything else is a display concern.

That separation is what allows the rest of the interface to be aggressively cached: the expensive guarantee is needed only on the cheapest path.

What the client must handle

• Showing that a value changed. If an item became unavailable while the user was browsing, silently removing it is worse than telling them — and the recovery path (substitute, remove and re-price) must be designed rather than being a generic error.
• Cache invalidation on the events that matter: a completed order, a location change, an account switch. A location change is the one most often missed, and it invalidates almost everything since availability is location-scoped.
• Bounded storage with eviction, since an unbounded local cache exhausts device storage.
• Behaviour with no connectivity, which for browsing can be the cached view with a clear indicator and for ordering must be a refusal rather than a queued action the user believes succeeded.

The measurement that reveals whether it works

The rate at which a cached value turns out to be wrong at commitment. A high rate means the tolerance is too loose and users are experiencing failures at the worst moment; a rate of zero means the caching is more conservative than it needs to be.

That number is a product decision expressed as a cache policy, and it should be tuned deliberately rather than being whatever the default was.