3 Consistency Patterns: Strong, Eventual, Weak and Why They're Worth Your Time

Data consistency models (or patterns), you might not think about them, but they're everywhere. They're making sure the system you use every day stays in one piece.

Photo by Pawel Czerwinski on Unsplash

Data consistency models (or patterns), you might not think about them, but they’re everywhere. They’re making sure the system you use every day stays in one piece, and that’s what we’re talking about here.

This isn’t a lecture, and we’re not here to make things complicated. We’re going to talk about how these models work in the real world, in ways that actually make sense.

1. Consistency

In the context of the CAP theorem, consistency is straightforward: “all nodes in a distributed system show the same data, all at once. This uniformity ensures that every time someone checks the data, they see the most recent information that’s been written.”

The CAP theorem presents a challenge: it states that a system cannot have more than two of the following at the same time: Consistency, Availability, and Partition Tolerance.

a. The Social Media

Think about a social media platform, a user posts something new. This post should appear to everyone, no matter where they are and almost immediately.

For instance, if a post goes up in Asia and a friend in Europe should see it right away. But, is there a need for such rapid updates for something as simple as a social media status?

And that’s the point of consistency patterns.

b. Challenges Across Data Centers

For a distributed system to work fast globally, the same data is stored in many data centers. These centers (or nodes) are identical copies situated in different parts of the world like Europe, Asia, and North America.

Here’s a potential problem: what if someone wants to read data from the European center at the exact time someone else is writing data in the Asian center?

By the end of this story, you’ll understand the patterns this system follows and have answers to these questions.

c. 3 Consistency Patterns 

When we talk about consistency patterns in distributed systems, we’re really talking about keeping the system’s behavior on the straight and narrow, even as it “sprawls” across more and more nodes or processes.

What does a consistency pattern really do? 

Simple, it sets the rules for how and when different parts of the system get to see the changes made to the data.

1. Strong Consistency: After an update, everyone can access the new data right away, no waiting around.

2. Eventual Consistency: Updates don’t spread instantly, but given a bit of time, all parts of the system will catch up with the new data.

3. Weak Consistency: It makes no guarantees about when the updates will be visible, allowing for a more ‘go-with-the-flow’ approach to data synchronization.

Consistency Patterns (source: blog.devtrovert.com)

“Do you oversimplified things? it’s cannot that’s be easy”

Unfortunately, yes.

It’s not just about striking a balance with availability, it’s about managing trade-offs between consistency, the system’s performance and the tolerance for fault or delay.

2. Strong Consistency 

Here’s the deal with strong consistency: “After a write, any following read received the most recent write data.” and that’s the basic expectation, isn’t it?

“And what’s the cost?”

Strong consistency reduces availability and slows down response times. It’s a demanding process, keeping every part of the system informed about each change. Every request has to wait its turn until the entire system is on the same page, prioritizing correct data over quick access.

CAP Theorem — C: Consistency (source: blog.devtrovert.com)

You change A to 2, this new information must be sent to all servers. While that’s happening, all operations about A is paused. Nothing proceeds until the “A is 2” message reaches everywhere.

Why does this matter?

Think about financial transactions, areas requiring precise and trustworthy data. Inconsistencies can cause big problems, it’s unacceptable for one server to show you have 1$ when another server at the same moment claims you have 1000$.

In conclusion, strong consistency takes more time and resources but it’s critical where accuracy is non-negotiable.

3. Eventual Consistency 

Eventual consistency doesn’t force immediate updates across all nodes. Instead, there’s a delay before changes reflect everywhere, so this approach guarantees that, if there are no new updates for a certain period, all copies of the data will eventually match.

“Why choose this? Are we compromising on data reliability?”

Somewhat, yes, but it serves our goals. 

Consider a social media status update, it doesn’t ruin anyone’s day if the change appears for different users at slightly different times. The system chooses function over perfection, accepting minor inconsistencies for broader availability.

If a system uses strong consistency patterns, this will a burden for but the need of user want reliable data for this case is small.

CAP Theorem — A: Availability (source: blog.devtrovert.com)

Another example is when you change the IP address for a domain by updating its DNS records, it doesn’t reflect immediately across all DNS servers worldwide but after at max 72 hours, it ensure the data is reflected. 

DNS Propagation (source: blog.devtrovert.com)

However, this method isn’t without drawbacks.

The big one: you’re often dealing with outdated information, leading to conflicts across the system. Also, a common but imperfect solution is the ‘last write wins’ strategy, it’s simple but brutal and can sometimes result in lost data.

4. Weak Consistency

In the weak consistency model, there’s no immediate synchronization across all participating elements. 

Unlike eventual consistency, which promises uniformity after a certain lag, weak consistency operates without ensuring that all nodes reflect the same data simultaneously.

Streaming Example

Take live video streaming, a clear case of weak consistency in action. In this environment, the data (meaning the video stream) doesn’t have to be perfectly aligned across all nodes. 

So, what’s critical? Maintaining that “live” experience and steady flow, a minor delay in synchronization can disrupts the entire purpose of the service.

With a poor network, user still experience some jitter or frame loss, but everything is still “live”.

“What if I use eventual consistency for live-streaming?”

The results wouldn’t be ideal, there’s a pause or buffering in the middle of a stream for a whole minute. Your device isn’t receiving real-time data. When buffering concludes, you’re in catch-up mode.

You have two less-than-perfect solutions: either skip or speed up. 

If you skip, you bypass the buffered minute, but if you speed up, you see that lost minute, but at an accelerated rate (~5x, 10x).

Live streaming demands the here-and-now, that’s why weak consistency isn’t just preferable, it’s essential.