Consistency Level Selection

Consistency is not a system-wide setting to be chosen once. Different operations in the same application legitimately need different guarantees, and treating it as one decision produces either unnecessary latency everywhere or incorrect behaviour somewhere.

Worked example from a single e-commerce system: a payment requires strong consistency and linearised ordering — the cost of getting it wrong is financial and legal. Inventory decrement at the moment of sale needs strong consistency for the last unit and tolerates staleness in the browse view. Recommendations tolerate minutes of staleness with no consequence. Order status needs read-your-own-writes for the customer who just acted, and eventual consistency for everyone else.

The intermediate guarantees are what make this tractable, and they are cheaper than full linearisability: read-your-writes (a user sees their own changes), monotonic reads (never seeing time go backwards), consistent prefix (updates observed in order).

The practical questions to ask of each operation: what does the user do if this is stale; is the staleness detectable; and is the resulting error recoverable? An overselling incident that costs a refund is different from an overdraft that costs a regulatory finding.

Then implement deliberately — routing reads to the primary where it matters, using replicas where it does not, and stating the choice in the design rather than inheriting it from a default.