CAP theorem gets cited constantly and understood precisely a lot less often. It's not a permanent three-way trade-off you're always making — it's a statement about what happens during a network partition, specifically. Get that distinction right and the rest of distributed data design gets a lot more tractable.
- CAP theorem describes behavior during a network partition — not a constant, all-the-time trade-off. Outside of a partition, you can often have both consistency and availability.
- "Choosing CP or AP" is usually a per-operation decision in practice, not one setting for your whole system — different parts of the same application can make different choices.
- PACELC extends CAP to the normal case (no partition): even then, you're trading latency for consistency.
- Eventual consistency is fine for data that tolerates staleness (product catalogs, recommendation feeds); strong consistency matters where a single fact being briefly wrong causes a real problem (inventory counts, account balances).
What CAP theorem actually says
When a network partition occurs — some nodes can't talk to others — a distributed system must choose between Consistency (every read sees the latest write, or an error) and Availability (every request gets a response, even if it might be stale). You can't have both during the partition. The common misreading treats this as "pick two of three, forever" — but Partition tolerance isn't really optional in a distributed system; the real, ongoing choice is what happens when a partition occurs, which is far rarer than "every request, all the time."
PACELC: the more useful day-to-day framework
PACELC extends CAP with the case that actually dominates day-to-day operation: if there's a Partition, choose Availability or Consistency (that's the "PAC" part) — Else, even with no partition, choose Latency or Consistency (the "ELC" part). This is the framework that actually explains most database configuration decisions you make, because most of the time you're not dealing with a partition — you're deciding how much latency you're willing to trade for a stronger consistency guarantee on every normal request.
Consistency models, in practice
| Model | Guarantee | Typical use |
|---|---|---|
| Strong | Every read reflects the latest committed write | Account balances, inventory decrement at checkout |
| Eventual | Reads converge to the latest value, eventually, with no ordering promise | Product catalogs, view counts, recommendation feeds |
| Causal | Related writes are seen in order; unrelated writes may not be | Comment threads, chat messages |
| Session | A single client always sees its own writes, even if others don't yet | "You just updated your profile" scenarios |
Where this shows up in real .NET systems
Cosmos DB's five consistency levels are this table made concrete and tunable per request — Session (the default) is a pragmatic middle ground, Strong is available but disables multi-region writes, Eventual is the cheapest in request units. DynamoDB defaults to eventually consistent reads and makes you explicitly request ConsistentRead = true for strong consistency, at higher cost and only within a single region. A standard SQL Server or Postgres transaction is strongly consistent by default — it's the baseline every NoSQL consistency conversation is implicitly compared against.
// Cosmos DB: strong consistency for this one request, overriding the account default
var response = await container.ReadItemAsync<OrderDocument>(
id, partitionKey,
new ItemRequestOptions { ConsistencyLevel = ConsistencyLevel.Strong });
// DynamoDB: explicitly requesting a consistent read for this one query
var request = new QueryRequest
{
TableName = "Orders",
KeyConditionExpression = "PK = :pk",
ConsistentRead = true
};A worked example: checkout
Decrementing inventory at checkout is exactly the case for strong consistency — two customers racing to buy the last unit is a correctness problem, not a UX nitpick, and it's worth the extra latency and cost. The "customers who bought this also bought" recommendations on the same page are exactly the opposite case — showing data that's a few minutes stale costs nothing, and paying for strong consistency there is pure waste. The same checkout page, the same request, two different consistency decisions — which is the point: this is a per-operation choice, not a database-wide setting.