CAP Theorem — Part 2: Consistency Models and Implementation Strategies

What is this?

In Part 1 we treated "consistency" as a single light switch: on (correct) or off (stale). That was a useful lie. In reality, consistency is a dimmer, with a whole spectrum of settings between "every observer sees the exact same truth at the exact same instant" and "everyone agrees eventually, give or take."

Go back to our dinner-planners. Strong consistency is them sharing a single live document that updates for both at once — change the restaurant and the other person sees it immediately. Weaker models are more like texting: messages arrive, but maybe out of order, maybe delayed, and occasionally you reply to something before you've seen the message that came after it. Each model is a different contract about what surprises you're allowed to experience. Your job as an engineer is to pick the weakest contract your application can tolerate — because weaker consistency buys you lower latency and higher availability.

The one-line idea: consistency is not on/off — it's a spectrum of guarantees about the order and freshness of what you read, and choosing the right point on that spectrum is the central craft of distributed systems.