Eventual Consistency: Availability Now, Correctness Later

WHY IT EXISTS In a distributed system, enforcing that every node has the identical, most recent data at all times (strong consistency) is slow and brittle. If nodes can't communicate, the system might have to stop accepting writes to prevent inconsistencies, sacrificing availability. Eventual consistency was created to prioritize high availability, especially in the face of network partitions.

THE MENTAL MODEL Think of a group chat. When you send a message, it appears on your screen instantly. For others, it might arrive a moment later depending on their connection. For a short period, you and your friends have different views of the conversation history. Eventually, everyone's device catches up and shows the same messages. The system prioritized letting you send the message (availability) over ensuring everyone saw it at the exact same millisecond (consistency).

HOW IT WORKS When a write is made to a system using eventual consistency, it is accepted by one replica without waiting for other replicas to confirm it. This is called optimistic replication. That replica then propagates the update to other nodes in the background. During this replication lag, reading the same data item from different replicas might yield different values—one new, one old. If all updates to that item cease, the propagation process will complete, and all replicas will converge on the final, correct value.

WHEN TO USE IT Use eventual consistency when your business logic can tolerate temporarily stale data and high availability is the top priority. This is common in large-scale applications like social media feeds (a stale 'like' count is not critical), e-commerce shopping carts (not the final checkout), or user session data. It allows the system to remain responsive and accept writes even if parts of it are disconnected.

WHEN NOT TO USE IT Avoid eventual consistency for operations that require immediate, transactional accuracy. Financial systems, banking ledgers, and inventory management systems are poor candidates. You cannot afford for a user to see an incorrect bank balance or for the system to sell an item that just went out of stock because a replica hadn't received the update yet.

ONE CANONICAL EXAMPLE The Domain Name System (DNS) is a globally distributed, eventually consistent system. When an administrator updates a DNS record (e.g., pointing a domain to a new IP address), that change is not instantaneous worldwide. It propagates through a hierarchy of servers, with each server caching records for a certain time. For a period, some users might be directed to the old IP while others get the new one, until the update has eventually reached all relevant servers.