A hotel reservation platform shows ten rooms remaining while thousands of users are viewing the property. Which operations require strong consistency and which can safely use stale cached availability?

Splitting the workload

The mistake is treating "availability" as one thing. It is at least three, with different guarantees.

Browsing and search results — stale is fine. A user scanning a results page needs plausible availability, not truth. Serving from a cache seconds or even a minute old is correct: it is fast, it survives the inventory system being degraded, and the cost of being wrong is a user who clicks through and sees a corrected number. Insisting on strong consistency here means every search fans out to the system of record, which is both slow and a reliability liability.

The property page — stale with an honest signal. Here the number is prominent and shapes behaviour. Still cacheable, but with a short TTL and, more importantly, with the scarcity signal treated as advisory. "Only a few rooms left at this price" is robust to staleness in a way that "exactly 10 rooms left" is not — which is a design argument for the vaguer phrasing.

The reservation — strongly consistent, always. This is the only operation that must be linearisable, because it is the only one where being wrong creates an obligation you cannot honour. Overselling costs money, trust and often regulatory exposure, and it cannot be resolved by an apology.

How the reservation is actually made safe

• Conditional decrement at the system of record, not read-then-write. The decrement either succeeds against current state or fails; there is no window between check and act.
• A short-lived hold created at the start of checkout, with an explicit expiry, so payment latency does not hold inventory indefinitely and an abandoned cart self-heals.
• Re-validation at the moment of commit, because everything the user saw before this point was allowed to be stale.
• Idempotent booking creation, so a client retry after a timeout does not create a second reservation.

The PACELC reading

Under a partition (P), the reservation path chooses consistency over availability — better to refuse a booking than to accept one that cannot be honoured. Else (E), in normal operation, browsing chooses latency over consistency, aggressively.

That is the useful form of the theorem: not a property of the system, but a decision made per operation, and the architecture's job is to make the boundary between the two explicit rather than accidental.

The failure this prevents

The classic incident is a cache used to make the reservation decision because it was already there and it was fast. It works under normal load and oversells during exactly the surge that made caching seem necessary.