Consistency Trade-offs

Gilbert and Lynch's formalization of what's known as the CAP theorem gives a precise shape to a trade-off every distributed system eventually faces: when a network partition splits nodes so they can't talk to each other, a system serving a write on one side has to choose between answering it locally — risking that side disagreeing with the other once the partition heals — or refusing to answer until the partition resolves. The first choice sacrifices consistency for availability; the second sacrifices availability for consistency. Outside of a partition, most real systems are also choosing along a related axis on every single request: how strong a guarantee does this particular read need, and what does that guarantee cost in latency.

DynamoDB's own documentation makes that per-request choice explicit rather than baking one answer into the whole system. The default is an eventually consistent read: it may not reflect a very recent write, but if you retry shortly after, it converges — and AWS states plainly that eventually consistent reads cost half as much as the alternative. A strongly consistent read asks for the most up-to-date data reflecting every successful prior write, at the cost of higher latency and more throughput capacity consumed; DynamoDB doesn't even offer it as an option on global secondary indexes, only on the base table and local secondary indexes. That's consistency treated as a per-read dial, not a single property the whole database either has or lacks.

The design move is to make that choice deliberately, per operation, rather than defaulting the whole system to the strongest guarantee everywhere. A dashboard showing a follower count can read eventually consistent — a count that's a few seconds stale costs nothing real. A checkout flow confirming that an item is still in stock before charging a card needs a strongly consistent read at that one point, even though every other read on the same page can stay eventual. Naming, out loud, which reads in a design need which guarantee is exactly the kind of non-functional detail an interviewer is listening for — it shows the trade-off was chosen, not defaulted into.