A booking platform must decide where strong consistency is required. How should the decision be made, and how is it communicated to application developers?

How the decision should be made

Per invariant, not per system. The question is never "is this system consistent" but "which invariants cannot be violated even briefly, and where are they enforced".

For a booking platform:

• Overselling cannot be violated. It creates an obligation you cannot honour and no apology fixes it. The reservation is linearisable at a single authoritative owner, with a conditional atomic decrement rather than read-then-write.
• A user's own recent write must be visible to them. Not seeing your own change looks like the system lost it.
• Search results may be stale by seconds. Insisting otherwise means every search reaches the system of record, which is slower and a reliability liability.
• Displayed availability may be stale, provided the commit step re-validates. This is what makes the read path cheap and the write path correct.

The pattern: find the invariant that cannot be compensated, protect it properly, and refuse to pay for strong consistency anywhere else.

How it is communicated to developers

This is the half that is usually neglected, and it determines whether the design survives.

• Document the guarantee per operation, in the API and in the internal service contract. "This read may be up to N seconds stale" prevents a class of bug for one sentence.
• Make the weaker guarantee visible in the interface, so a stale read is obviously a stale read — a separate method, a freshness field, an explicit parameter.
• Never allow a stale read to feed a decision that requires freshness. The most common real incident is a cached availability read used to make the reservation decision because it was already there and fast.
• Provide a way to ask for the strong version where it is legitimately needed, so developers are not forced to invent one.

The organisational point

An unstated guarantee is assumed to be the strongest one. Developers building on an internal service will assume read-after-write unless told otherwise, and will build workflows that fail intermittently at exactly the points where the system is eventually consistent.

Publishing the guarantees — including the ones you do not provide — is what makes eventual consistency safe to build on.