Eventual consistency vs. strong consistency: trade-offs in distributed systems

In distributed system design, there is no one-size-fits-all consistency model.

A banking application allowing a user to transfer money cannot tolerate eventual consistency (which could lead to catastrophic double-spending). Conversely, requiring strong consistency for social media like counts or follower counters would crush database throughput and cause global latency spikes.

┌──────────────────────────────────────────────────────────────────────────┐
│                   CONSISTENCY SPECTRUM COMPARISON                        │
├───────────────────┬──────────────────────┬───────────────────────────────┤
│ Consistency Level │ Latency & Throughput │ Best Use Cases                │
├───────────────────┼──────────────────────┼───────────────────────────────┤
│ Strong            │ Higher latency (2PC) │ Bank Balances, Inventory, Auth│
│ Eventual          │ Sub-5ms async speed  │ Likes, Feeds, Analytics, Logs │
└───────────────────┴──────────────────────┴───────────────────────────────┘

1. Strong Consistency (Linearizability)

In a strongly consistent system, once a write operation completes, any subsequent read from any client is guaranteed to return the updated value.

How It Works:

When a write arrives, the primary database node coordinates with replica nodes via consensus protocols (such as Raft, Paxos, or Two-Phase Commit / 2PC).
The write is not acknowledged until a majority quorum confirms data persistence.

Trade-offs:

Higher Latency: Writes must wait for cross-network round-trip acknowledgments.
Availability Risk: If network partitions isolate nodes, writes block or fail to prevent split-brain divergence.

2. Eventual Consistency

In an eventually consistent system, the primary node writes data locally and acknowledges the client in under 2 milliseconds.

Client ──[1. Write Post]──▶ Primary DB (Ack in 2ms)
                              │
                              └──[2. Async Gossip (50-200ms)]──▶ Read Replica A
                              └──[2. Async Gossip (50-200ms)]──▶ Read Replica B

The Stale Read Window:

Because replicas are updated asynchronously via background gossip protocols:

If User A likes a post, and User B immediately queries Replica B 30ms later, User B may temporarily see the stale count.
Within 100–300ms, all replicas eventually converge to the identical state.

Benefits:

Ultra-High Throughput: Zero cross-region locking; databases like Amazon DynamoDB, Apache Cassandra, and Redis can process millions of writes per second.
99.999% Availability: Even if multiple replicas are disconnected, local nodes continue servicing reads and writes.

3. The PACELC Theorem

While the CAP theorem describes system behavior strictly during network partitions (P), the PACELC Theorem extends it to normal operating conditions:

If there is a Partition (P): Trade off between Availability (A) and Consistency (C).
Else (E): Trade off between Latency (L) and Consistency (C).

       PACELC
      /      \
If Partition   Else (Normal)
  /       \      /         \
 (A)      (C)   (L)        (C)
Avail   Consist Latency  Consist

4. Architecture Decision Matrix

Domain Requirement	Chosen Model	Recommended Storage Engine
Financial Ledger / Double-Entry Ledger	Strong Consistency	PostgreSQL / CockroachDB / Spanner
E-Commerce Inventory Stock	Strong Consistency	PostgreSQL / Redis Lua Scripting
Social Media Feed & Timelines	Eventual Consistency	DynamoDB / Cassandra / ScyllaDB
Video View Counts & Metrics	Eventual Consistency	ClickHouse / Redis HyperLogLog
DNS Record Propagation	Eventual Consistency	Route 53 / Cloudflare DNS