Consistency Choices

Definition

Consistency is not a system-level property to be selected once. It is a per-operation decision, and the discipline is to identify the weakest guarantee that keeps each operation correct, because stronger guarantees cost latency, availability and money.

The decision procedure

For each operation ask:

1. What breaks if this read is stale by five seconds? If the answer is "nothing anyone notices", eventual consistency is correct and cheaper.
2. Is there a cross-row or cross-entity invariant? Two bookings for the same night, a balance that must not go negative, an approval limit. These need serialisable isolation or a materialised conflict point.
3. Is the failure recoverable? A false decline is an annoyance the customer retries. A double charge is unrecoverable and scales with the duration of the problem. Asymmetry of failure cost is what decides CAP questions in practice.
4. Does the user need to see their own write? Read-your-own-writes is a much weaker and cheaper requirement than global strong consistency, and it satisfies most complaints.

The shape most systems converge on

Search and browse are eventually consistent; the commit is strongly consistent and authoritative.

A marketplace shows listings from an asynchronously updated index, which may be seconds stale, and re-validates availability at the moment of booking with a conditional write. Trying to make search strongly consistent is enormously expensive and unnecessary; letting the commit trust search is a correctness bug.

This same shape recurs in inventory, ticketing, seat selection and capacity reservation.

The session guarantees worth knowing

Between "strong" and "eventual" sit several cheap and useful guarantees:

• Read-your-writes — you see your own changes.
• Monotonic reads — you never see time go backwards.
• Consistent prefix — you see writes in a causally sensible order.

These cost far less than linearizability and resolve most user-visible weirdness. Reaching for them before reaching for strong consistency is the mark of someone who has done this before.

Failure scenarios

• One consistency model chosen for a whole system, so either everything is slow or something is wrong.
• Eventual consistency where an invariant lives, producing double-booking.
• Strong consistency on a read path that never needed it, paying cross-region latency for a product listing.
• Staleness not surfaced, so consumers assume currency.

Interview question

"Which operations in a ticketing system need strong consistency, and which are correct with eventual consistency? Justify each."