You're designing a multi-region e-commerce platform and need to decide where different features - shopping cart, inventory count, order history - sit on the consistency spectrum from linearizable down to eventual. Walk through how you'd choose, and name a real system that lets you tune this per operation.

## The method Real production systems rarely pick a single consistency model for an entire application; the practical skill is mapping each distinct operation or feature to the weakest model on the spectrum, linearizable down through sequential, causal, client-centric, and eventual, that still avoids a genuine business-level correctness problem. Every step up the spectrum toward stronger guarantees costs latency, throughput, or availability, while every step down risks a visible or silent correctness bug if chosen carelessly. ## Mapping the features of one platform Concretely, consider an e-commerce platform's three example features. - **Shopping cart.** A shopping cart's add and remove operations are naturally scoped to a single user and low-conflict, since nobody else is editing your cart, so a client-centric guarantee, read-your-writes so the shopper always sees their own edit immediately, plus monotonic reads so the cart never appears to go backward, is exactly enough; there is no need for global ordering across all shoppers' carts. - **The stock badge.** An 'X items in stock' badge shown to browsing shoppers is a display-only, informational field where a few seconds of staleness has essentially no cost, making eventual consistency a fine, cheap fit. - **The inventory decrement.** The actual inventory decrement that happens at checkout is different in kind: allowing two concurrent checkouts to both succeed past a stock count of zero is a real, costly business failure, oversold inventory, refunds, damaged trust, so that specific write needs a strong guarantee, typically a linearizable conditional write or a quorum-based counter, even while the rest of the catalog stays on cheaper models. - **Order history.** Order history sits in between: an order confirmation must always appear after the payment event it depends on, a causal relationship, but two different customers' unrelated orders need no relative ordering between them, making causal consistency the natural fit. ## The per-operation knob Real systems increasingly expose this as an explicit, per-operation knob rather than forcing an all-or-nothing choice. **Azure Cosmos DB** is the most explicit industry example: it offers five named, selectable consistency levels. | Level | What it gives you | |---|---| | **strong** | or linearizable | | **bounded staleness** | reads lag writes by a bounded time or operation count | | **session** | bundles read-your-writes and monotonic reads scoped to a client-held session token and is the default level because it fixes the most common perceived-bug complaints cheaply | | **consistent prefix** | reads never see writes out of the order they were originally written though gaps are allowed | | **eventual** | no ordering guarantee beyond convergence | All five are configurable per container or overridable per individual request. - **Amazon DynamoDB** offers a simpler two-way version of the same idea: a per-request 'ConsistentRead' boolean lets a caller pay for a strongly consistent read exactly when it needs one, defaulting to cheaper eventually consistent reads otherwise. - **Apache Cassandra** exposes a tunable consistency level per query, ONE, QUORUM, ALL, and others, letting a team dial the number of replicas that must acknowledge a read or write independently for every single query in the codebase. ## What mixing models costs The trade-off of this per-operation approach is organizational and cognitive, not just technical: mixing consistency levels across features that reference each other creates new subtle failure surfaces that don't exist in a single-model system. In the inventory example, the badge and the checkout decrement can legitimately disagree at any instant, the badge might say '5 left' the moment checkout is failing the sixth concurrent buyer, and that's not a bug, but it is something every engineer touching that code needs to understand, or they'll wrongly treat the badge number as authoritative for a business decision it was never meant to support. Teams adopting tunable consistency take on a real documentation and testing burden: - every field or operation needs an explicit answer to which consistency level it uses and why; - test suites need to exercise the actual staleness or reordering windows the weaker levels permit, not just the happy path. ## Getting it wrong, in both directions The most common production failure mode from getting this wrong runs in both directions. - **Too weak.** Choosing too weak a model for a correctness-critical path is the classic and most damaging mistake, flash-sale overselling incidents, where an inventory decrement was accidentally left on a weaker consistency level than checkout actually required, are a recurring real-world pattern across e-commerce platforms. - **Too strong.** The less-discussed but also real mistake is choosing too strong a model everywhere out of caution: forcing every read of a read-heavy, geo-distributed product catalog through a single linearizable leader adds unnecessary cross-region latency to the vast majority of traffic that never needed the guarantee, directly hurting tail latency and, ultimately, availability during any partition or leader failover, a cost paid continuously for a correctness guarantee only a small fraction of operations actually required.