Strong Consistency
Every read reflects the most recent write — the opposite of eventual consistency, at a latency and availability cost.
Strong consistency guarantees that once a write commits, every subsequent read anywhere sees it — a single, up-to-date view of the data. It is the intuitive model, and the costly one in a distributed system.
Worked example: a bank balance must be strongly consistent — after a withdrawal, every node must see the new balance immediately, or you could overdraw by reading a stale replica. Gotcha: strong consistency requires coordination (consensus, synchronous replication) that adds latency and, per CAP, sacrifices availability during a partition — which is why many systems choose eventual consistency where it is safe and reserve strong consistency for the data that truly needs it.