How Systems Stay Consistent: Strong, Eventual & Causal

When systems were simple and single-node, consistency was obvious—data either changed or it didn't. But modern distributed systems don't have that luxury.

We now operate across regions, across networks, across unreliable nodes, and often at a scale where failures are inevitable.

This is where Consistency Models matter. They determine how and when different parts of a distributed system see the same data. Three common models dominate real-world architectures:

1. Strong Consistency
2. Eventual Consistency
3. Causal Consistency

Strong Consistency

Strong Consistency guarantees that every read returns the most recent committed write across the entire distributed system — as if the data were stored in a single, centralized storage unit.

Regardless of which replica or data center you read from, the system behaves exactly like one authoritative source of truth.

This model is chosen when an incorrect value is more harmful than a slow response. Even brief reading of stale data could cause financial loss, fraud, incorrect ordering, negative inventory, or identity mismatches.

Therefore, strong consistency prioritizes correctness over speed and availability.

Why Strong Consistency Is Expensive?

In a distributed system, data isn't stored in one place — it must be copied across regions, racks, and nodes. To guarantee that all replicas agree on the latest value before anyone reads it, systems must:

1. Reach a Quorum

Before a write is considered successful, a majority of nodes must acknowledge the update. For example, in a 5-replica system, at least 3 replicas must successfully store the new value before the write is committed.

Suppose replicas A, B, and C acknowledge the write, while D and E are temporarily unavailable or slow.

Later, if a client performs a read from a majority (again, at least 3 replicas), the read set must overlap with the write set by at least one replica.

Since at least one of the replicas participating in the read has already stored the latest value, the system can identify and return the most recent data instead of a stale version.

2. Wait for Coordination (Consensus)

In a strongly consistent system, replicas cannot accept writes independently. They must first agree on the current leader and the exact order in which updates are applied so that every replica reaches the same state.

Consensus algorithms such as Raft and Paxos achieve this by replicating each write through the leader and requiring acknowledgements from the necessary replicas before the write is committed.

Client → Leader → Replicas → Leader → Client

Each additional coordination step introduces extra network round-trips and waiting time. The greater the distance between replicas—for example, across multiple datacenters or regions—the higher the latency.

Compared to eventually consistent systems, where writes can often be accepted locally and propagated asynchronously, strongly consistent systems make writes slower because they prioritize correctness over speed.

3. Potentially Block During Failures

If replicas cannot reach agreement—for example, due to a network partition, leader failure, split-brain scenario, or replica corruption—the system may temporarily reject new writes and, in some cases, even block reads until consensus is restored.

Although this reduces availability, it prevents clients from reading stale data or committing conflicting updates.

Rather than risking inconsistent data, the system waits until a majority of healthy replicas can safely agree on the next operation.

Example: Global Banking Balance Update

Imagine a bank that serves users from multiple countries, with replicated databases spread across regions:

India DC            →   Primary

US DC               →   Replica

Singapore DC        →   Replica

To guarantee Strong Consistency, the bank must ensure that a debit is visible immediately across all datacenters, otherwise a user might:

- withdraw ₹5000 in Mumbai
- immediately withdraw ₹5000 more in New York

even though the balance is only ₹5000. To prevent this, Banks use a strongly consistent distributed datastore.

A balance update is not considered successful until a majority of replicas acknowledge it.

Consensus Algorithms (Raft/Paxos)

Consensus algorithms ensure that all database replicas agree on the order of operations even if some replicas fail or messages arrive late.

They elect a leader, replicate writes in the same sequence, and only consider a write committed when a majority acknowledge it. This prevents conflicting updates and guarantees a single source of truth.

Synchronous Replication

In synchronous replication, a write is not considered successful until all required replicas have stored the data.

This ensures no data loss and immediate consistency, but increases latency because the client must wait for multiple nodes (possibly across regions) to confirm the write.

Eventual Consistency

Eventual Consistency is a consistency model where data updates do not need to be visible immediately across all replicas. Instead, updates are propagated asynchronously, and replicas "catch up" over time.

If no new writes occur, all replicas will eventually hold the same value. This behavior sacrifices immediate correctness in exchange for high availability, fault tolerance, and low-latency writes.

Systems choose eventual consistency when speed and availability matter more than instantaneous accuracy, and when stale data does not cause harm or financial loss.

Instead of forcing all replicas to agree before accepting a write, systems simply take the update locally and replicate it in the background.

This keeps the system responsive even during network partitions, spikes in traffic, or partial outages.

This model is common in:
- social feeds,
- counters (likes, views, shares),
- product catalogs,
- shopping carts,
- messaging timelines,
- analytics and metrics ingestion.

Example: Likes in a Social Media System

Imagine four replicas of a "likes" counter for a video:

Replica A (US)
Replica B (India)
Replica C (Singapore)
Replica D (Europe)

When a user taps "Like", their request hits the closest replica (e.g., Replica A in the US). Instead of waiting for others to update, Replica A increments immediately:

Replica A: 1,020 likes
Replica B/C/D: still show 1,019

Replica A asynchronously publishes the new like count to others through background replication:

A → B, C, D (eventual propagation)

Each region will update at its own pace, catching up milliseconds or seconds later. Even if other replicas temporarily fail, retries ensure they eventually catch up.

Causal Consistency

Causal Consistency ensures that if one operation logically depends on another, every replica must observe them in that same order.

The system does not enforce a global ordering of all operations — only those that share a cause–effect relationship.

This makes it less strict than Strong Consistency, but more meaningful than Eventual Consistency, because it preserves how users naturally perceive actions and interactions.

In simple terms:
- Causally related events must be seen in order
- Independent events can appear in any order

Consider a simple interaction:

A user posts a comment (Event A), and another user replies to it (Event B). Since B depends on A, every user in the system must see A before B.

If the reply appears before the original comment, the system technically still converges, but the user experience breaks.

How to achieve Causal Consistency?

To enforce causal consistency, systems must track dependencies between operations and ensure that no event is applied before its causal history is satisfied.

This is achieved through a combination of logical clocks, dependency tracking, and smart replication strategies.

1. Tracking Causality (Happens-Before Relationship)

At the core lies the concept of Happens-Before (→), which defines the relationship between events. If Event A → Event B, then B depends on A and must always be observed after A.

To track this, systems attach metadata to each operation. Two key techniques are used:

A) Lamport Timestamps: Lamport timestamps use a logical clock per node to assign an order to events. Each node increments a counter for every event and shares it with other nodes during communication.

However, Lamport timestamps only provide ordering, not full causality. They cannot distinguish whether two events are truly independent or causally related.

B). Vector Clocks: Vector clocks improve upon this by maintaining a vector of counters, one per node. This allows systems to not only order events but also detect whether events are causally related or concurrent.

2. Dependency-Aware Replication

Once dependencies are tracked, systems ensure that updates are applied only when their prerequisites are satisfied.

If an update arrives before its dependency, it is temporarily stored in a pending queue. This prevents invalid states like replies appearing before their corresponding messages.

Conclusion

There is no universally "best" consistency model—only the one that best fits your application's requirements.

Strong consistency guarantees that every client sees the latest committed data, making it ideal for systems such as banking, payments, and inventory management where correctness is critical.

Eventual consistency prioritizes availability and scalability, accepting temporary inconsistencies in exchange for higher performance.

Causal consistency strikes a balance by preserving the logical order of related operations without requiring global synchronization.

Modern distributed systems often combine multiple consistency models, applying strong consistency where data integrity is essential and weaker models where responsiveness and scale are more important.