Consistency Patterns
in Distributed Systems

SECTION 01

What a distributed system is

Before talking about consistency, it helps to align on a simple idea: a distributed system is an application split into several parts, each running separately, that communicate over the network to deliver one result.

Take an online bookstore. Instead of one server doing everything, the application might be split like this:

Each service has one responsibility and, often, its own database. The article on microservices in practice covers that split in more detail — here the question is narrower: what happens to the data once it is spread out like this.

SECTION 02

Why consistency is a problem

When data lives in more than one place, something has to make sure those copies do not tell different stories. Back to the bookstore: the Stock Service needs to know exactly how many copies of a book exist when someone tries to buy it.

Now imagine two customers looking at the same book — only 1 copy left — at the same time:

This is a classic race condition: between the moment Client B reads the stock and the moment the Stock Service finishes processing Client A's purchase, the information became stale — and nobody noticed in time.

That is exactly what consistency patterns define: when, precisely, a write made in one place becomes visible to a read made somewhere else.

SECTION 03

The three families of patterns

There is no universal answer to "when should data synchronize." There is a trade-off between three things: how fast the system responds, how available it remains when something fails, and how exact the information is. The most common consistency patterns make that trade-off in three ways:

Eventual consistency is not an entirely separate category — it is a specific, well-behaved form of weak consistency. It does not promise when a read will reflect a write; it only promises that, if no new writes arrive, all replicas converge to the same value over time.

SECTION 04

Strong consistency

The rule is simple to state: after a write completes, every following read — no matter which replica it hits — sees that write immediately. For that to work, replication must be synchronous: every copy is updated before the system confirms that the operation finished.

A financial system is the classic example: nobody should see an account balance "almost" updated. The cost is clear — because the system waits for all replicas to confirm before responding, latency rises and availability drops when a replica is down.

SECTION 05

Weak consistency

Here the promise is looser: after a write, a later read may see the change — or may not. There is no deadline and no ordering guarantee. That sounds risky, but it is exactly what makes sense when speed matters more than absolute precision.

In a multiplayer game, actions appear immediately for players close to the same server. If someone has lag or an unstable connection, that player may not see an action in time — and the game does not freeze waiting for them. That creates real inconsistency between screens, but also preserves the low latency the match needs.

SECTION 06

Eventual consistency

Eventual consistency takes weak consistency and adds one promise: if no new writes arrive, all replicas eventually converge to the same value. Replication is asynchronous — the system responds before propagating the change everywhere.

A social network is the intuitive example: data lives in several datacenters around the world. When someone posts, the update appears immediately in the local datacenter, but takes a little time to propagate to others. During that window, different people literally see different versions of the same feed — by design, not by accident.

SECTION 07

Comparing the three patterns

Side by side, the trade-off becomes easier to see:

No row in this table is "better" in absolute terms. Each pattern is right for a different kind of problem. That is why real large systems often mix all three, each applied to a different part of the architecture.

SECTION 08

How to choose in practice

Before choosing a pattern, three questions help diagnose what the data actually requires:

• Would wrong data cause real damage? Account balances, final payment stock, access permissions — these usually need strong consistency.
• Can the system afford to wait for synchronization? If not, some form of weak or eventual consistency is often necessary.
• Is a small propagation delay acceptable? Likes, view counts, feeds, caches and DNS usually tolerate eventual consistency.

This choice does not have to be global. In the bookstore from the beginning, payment may require strong consistency while the count of "how many people viewed this book today" can safely use eventual consistency.

SECTION 09

Conclusion

Consistency is not a yes-or-no box — it is a spectrum, and every point on it costs something different:

Strong consistency:
trades speed and availability for guaranteed correctness.

Weak consistency:
trades exactness for speed and high availability.

Eventual consistency:
accepts temporary delay, but guarantees convergence.

The right question is never "which consistency pattern is best." It is: "what can this specific data not afford to get wrong, and what can it afford to wait for?" Answering that data by data is what separates a well-designed distributed architecture from one that only seems to work until two orders arrive at the same time.