Understanding Eventual vs. Strong Consistency in Databases

Strong vs Eventual

Effective database design is critical for ensuring reliable data storage and access. Two important concepts in this regard are eventual consistency and strong consistency. Understanding these concepts can help in choosing the right strategy for your application’s needs. Let’s explore these ideas through a relatable story.

An Analogy to Simplify Understanding :

Imagine you have a diary where you jot down your daily thoughts and experiences. To prevent losing your notes, you decide to make copies. You use an external hard drive and a cloud service like Dropbox to back up your diary entries. Here’s how this relates to database consistency models:

• Master-Slave Model: Your laptop is the master where you write and read notes. The hard drive and Dropbox are slaves used mainly for reading and backups.
• Redundancy Increases Reliability: Backing up your notes in multiple places ensures that you have multiple copies, making your data more reliable and less prone to loss.

Case 1: Eventual Consistency

When you back up your diary, the hard drive gets updated every fortnight, while Dropbox updates whenever you connect to the internet. This introduces a delay in data synchronization.

• Eventual Consistency: In databases, when a write request is made to one replica, the data eventually propagates to other replicas, ensuring they all hold the same information. However, during the synchronization period, some replicas might return outdated data if read requests are made.

Analogy Example:

• You lend your hard drive (which has a fortnightly update schedule) to a friend, John.
• John: “I need your notes.”
• You: “Sure, but it hasn’t been updated for a few days.”
• John: “That’s okay.”

John gets the hard drive quickly (low latency) but with potentially outdated notes (stale data).

Case 2: Strong Consistency

Strong consistency ensures that once a write request is made, all replicas are immediately updated before any subsequent read or write requests are processed. This guarantees that any read request always returns the most recent data.

Analogy Example:

• Your friend Veronica asks for your latest notes.
• Veronica: “I need your latest notes.”
• You: “I’ll share a Dropbox link. Access it after a few minutes; my recent notes are syncing.”

Veronica waits a bit (high latency) but gets the most up-to-date notes.

Choose the Right Model for Your Needs:

• If your application can tolerate stale data and prioritizes quick responses, eventual consistency might be the way to go.
• If your application requires the most recent data for every request and can tolerate some delay, strong consistency is preferable.

Designing databases with the appropriate consistency model ensures they meet your application’s performance and reliability needs effectively.

Conclusion :

• Eventual Consistency: Offers low latency but might return stale data since not all replicas may be updated immediately.
• Strong Consistency: Ensures up-to-date data but at the cost of higher latency due to the synchronization delay.

Understanding these models helps in choosing the right consistency strategy based on your application’s requirements for data freshness and access speed.

That’s it!. Feel free to follow me and share your thoughts on what else I can improve.

Do checkout the my complete ongoing series on System Design —

jaspreetsodhi02.medium.com/list/system-design-series-f5054fed26fd

See you in the next part! 😊