Eventual consistency in plain words

Eventual consistency

A replicated system is strongly consistent if every read, anywhere, returns the latest write, as if there were only one copy. It is eventually consistent if replicas are allowed to be temporarily out of date, with the guarantee that once writes stop, all copies converge to the same value.

Eventual consistency is not sloppiness, it is a deliberate trade. To be strongly consistent, a write must reach every replica (or a majority, next lesson) before it is confirmed, making writes slower and impossible during network trouble. To be eventually consistent, a write can be confirmed by one node and spread in the background, staying fast and available.

Most of the real world runs eventually consistent and nobody notices: a like count that is 2 seconds behind harms no one. The skill is naming the data where staleness does harm, money, inventory, permissions, and paying the consistency cost only there.

The CAP intuition

Now the famous theorem, minus the fog. Replicas talk over a network, and networks sometimes break so that node groups cannot reach each other: a partition. During a partition, a replica receiving a read has exactly two options:

1. Answer from what it has, possibly stale. The system stays available but gives up consistency
2. Refuse or wait until it can check with the others. The system stays consistent but gives up availability

That is the CAP theorem: when a Partition happens, choose Consistency or Availability. You cannot dodge the choice, because partitions are not optional, the network decides when they happen.

Banking systems choose C: better to show an error than a wrong balance. Social feeds, DNS, and shopping carts usually choose A: better slightly stale than down. Real systems choose per feature, not per company.