Eventual Consistency

Introduction to Eventual Consistency

If you deposit a check into your bank account, you expect your balance to update immediately. If you check your balance on your phone 10 seconds later and the money isn’t there, you will panic. This is because banking systems require Strict Consistency (ACID compliance).

However, enforcing Strict Consistency across a globally distributed database is incredibly slow. Every time a user posts a tweet on X (formerly Twitter), the server in California would have to freeze, contact servers in Tokyo, London, and Sydney, wait for them to save the tweet, and only then tell the user “Tweet Successful.” The app would take 5 seconds to load every action.

To achieve blazing-fast performance at global scale, modern web applications abandon Strict Consistency and embrace Eventual Consistency.

Eventual Consistency is a theoretical guarantee that, provided no new updates are made to a given piece of data, all servers in the system will eventually return the last updated value.

The BASE Philosophy

Eventual Consistency is the cornerstone of the BASE database philosophy (the direct opposite of the traditional ACID philosophy).

• Basically Available: The database prioritizes keeping the application online above all else.
• Soft State: The state of the database is allowed to change over time, even without user input, as background servers sync with each other.
• Eventually Consistent: The system does not guarantee that you will see the latest data immediately, but guarantees it will sync eventually.

How Eventual Consistency Looks in the Real World

You interact with Eventual Consistency every single day.

• Social Media Likes: You post a picture on Instagram. You refresh the page and see it has 5,000 likes. Your friend in Europe looks at the exact same picture at the exact same millisecond and sees 4,980 likes. For a few minutes, the servers disagree on reality. Eventually, the European servers sync with the US servers, and both show 5,000.
• DNS Changes: When a company registers a new website domain name, they are told “It may take up to 48 hours for this change to propagate globally.” This is the ultimate example of eventual consistency across the global internet infrastructure.

Handling Conflicts

Because Eventual Consistency allows two different servers to accept writes simultaneously without talking to each other first, it inevitably leads to Conflicts.

Imagine an airline booking system built on eventual consistency:

1. User A (in New York) buys Seat 12B. Server A records the sale.
2. User B (in London) buys Seat 12B at the exact same time. Server B records the sale.
3. Five minutes later, Server A and Server B sync and realize they sold the same seat twice.

How does the database resolve this?

1. Last Write Wins (LWW): The database looks at the exact millisecond timestamp. Whichever user clicked “Buy” last gets the seat. The other user receives an apology email.
2. Vector Clocks: A mathematical algorithm that tracks the exact causal history of updates to determine which version of reality is correct.
3. Application Logic Resolution: The database gives up and hands both conflicting records to the application developer, forcing the developer to write custom code to handle the conflict (e.g., merging two shopping carts together).

Conclusion

Eventual Consistency is the architectural engine of the modern, ultra-fast internet. By giving up the comfort of mathematical perfection and embracing temporary, localized chaos, data engineers can build global distributed systems (like Amazon DynamoDB and Apache Cassandra) that are infinitely scalable, highly available, and capable of serving petabytes of data to billions of users with zero latency.