Consistency

Consistency is one of the most misunderstood concepts in distributed systems.

Two main reasons explain this confusion.

The term consistency is used in multiple, distinct contexts.

Engineers working with relational databases know ACID.

In ACID, C stands for consistency.

This refers to transaction-level consistency: database constraints must not be violated during execution.

For example, when transferring money between accounts, the total balance must remain unchanged.

NoSQL engineers know BASE.

In BASE, E stands for eventual consistency.

This refers to data replication and convergence over time.

Casino databases introduce tunable consistency.

The CAP theorem includes a consistency dimension.

These terms do not describe the same concept.

ACID consistency ensures transaction integrity.

The other three refer to data replication and synchronization across multiple copies.

These replication-based models are not equivalent.

Each implies a different system behavior.

We will explore these differences later.

Reading the Wikipedia page on consistency models is overwhelming.

Still, understanding nuances is essential.

I will distill key concepts and focus on them.

In the early 2000s, engineers worked with simple systems.

A single database instance could serve many popular websites.

This was common, though I may exaggerate.

History has since become myth.

The key point: there was one single copy of data at any time.

When a client successfully wrote data, the change was immediately visible to others.

All clients observed the same data value.

Application development and testing were straightforward.

Writing to the database and reading from it always yielded predictable results.

Internet traffic grew rapidly.

Data replication became necessary, especially for social media platforms.

The primary driver was not durability, but read scalability.

Social media sites are read-heavy.

Each node can serve read requests independently.

Replication also improves availability and durability.

With multiple data copies, two design choices emerge.

First: maintain behavior identical to a single-copy system.

All copies must remain synchronized at all times.

This implies strong consistency.

Second: accept that copies can be out of sync for a reasonable period.

Multiple versions of data can coexist.

This implies weak consistency.

Early engineers recognized that terms like strong and weak are vague.

How strong? How weak?

What if a new consistency model exists—stronger than weak, weaker than strong?

How should it be named? Medium?

To avoid ambiguity, specific names were assigned to distinct consistency types.

This ensures clarity and precision in system design.

People defined a set of rules for each consistency type to specify the order of updates and when those updates become visible to users.

These rules form a consistency model. Many such models exist in distributed systems.

Linearizability is the strongest consistency model achievable in distributed systems.

Strict consistency exists in theory but cannot be implemented in practice.

Thus, linearizability is the strongest practical model.

Linearizability ensures that after an update completes, all clients reading data receive the updated value.

Even with multiple data copies, the system creates the illusion of a single copy.

When someone mentions strong consistency in distributed systems, they usually mean linearizability.

It's best to confirm this with the speaker.

Linearizability is easy to reason about and is used in systems tracking balances.

Examples include bank account balances, online shop product inventories, and airline ticket counts.

In such systems, all clients must see the same balance after a change.

First, linearizability is slow.

Second, the CAP theorem states that during a network partition—network failure—we must choose between consistency and availability.

We cannot have both.

The CAP theorem has many nuances and deserves its own video.

For now, remember two key points:

• C in CAP stands for strong consistency, specifically linearizability.

• We only need to choose between consistency and availability during network partitions.

If the network is reliable, both availability and strong consistency can be maintained.

Many systems prefer eventual consistency over linearizability.

Eventual consistency guarantees that if no further updates occur, all reads will eventually return the latest written value.

This happens after all replicas are synchronized.

Eventual consistency does not specify when replication completes.

If there are no system failures, replication occurs quickly—within milliseconds or seconds.

However, during failures, some replicas may fall behind.

These replicas will continue returning older values when queried.

Other replicas return the updated value.

Eventual consistency is faster than linearizability, especially when replicas are geographically distributed.

It also does not require sacrificing availability.

We can maintain both availability and eventual consistency during network partitions.

Eventual consistency can cause user confusion.

For example: a user sees one comment on a blog post.

After refreshing, the comments disappear.

This occurs because the first read came from one replica.

The second read hits a replica that hasn't yet received the update.

Another example: a user writes a comment and sends it.

After refreshing, the comment does not appear on the page.

This happens because the replica handling the read has not yet synchronized.

The user sees an inconsistency between what was written and what is displayed.

After multiple page refreshes, a user finally sees their comment.

The comment hasn't reached all system replicas yet.

The replica used to display the content lacks the new comment.

A user adds a second comment to clarify their first.

After pressing send and refreshing, both comments appear on the page.

But the order is reversed: the second comment appears before the first.

This breaks the logical flow of the message.

The system uses multiple shards, each with its own set of replicas.

The first comment is processed by one shard.

The second comment is processed by a different shard.

Even though the first comment was created earlier, the second shard completes replication faster.

A similar issue arises if shards have different clock times.

The system interprets the second comment as older due to replication timing.

Older engineers developed consistency models to address these issues.

These models are stronger than eventual consistency.

They are weaker than linearizability.

• Monotonic reads solves the first problem.
• Read-your-writes solves the second.
• Consistent prefix reads solves the third.

The slide orders models by strength.

This is not accurate.

No model is stronger than another.

All three models are stronger than eventual consistency.

All three are weaker than linearizability.

The visual ordering does not reflect actual strength relationships.

These models exist as a spectrum, not a hierarchy.