Strong consistency (also called linearizability) is a consistency model where every read operation returns the value of the most recent completed write. The system behaves as if there is only a single copy of the data, and all operations execute atomically in real-time order.
Guarantees
Under strong consistency:
- Recency: Reads always see the latest write
- Global order: All operations appear to execute in a single, total order
- Real-time: If operation A completes before operation B begins, all nodes see A before B
This creates the illusion of a centralized system despite distribution across multiple nodes.
Implementation Cost
Achieving strong consistency requires:
- Synchronous coordination: Nodes must communicate before responding
- Blocking on failures: Operations may stall if quorums unavailable
- Higher latency: Coordination overhead increases response times
Traditional approaches include:
- Single-leader replication with synchronous writes
- Consensus protocols (Paxos, Raft)
- Two-phase commit (2PC)
Trade-offs
The CAP-theorem shows that strong consistency conflicts with availability during network partitions. Systems must choose:
Strong consistency (CP systems)
- Reject operations when partition prevents coordination
- Example: Traditional relational databases
- Best for: Financial transactions, inventory systems
Eventual Consistency (AP systems)
- Accept operations during partitions, reconcile later
- Example: Dynamo
- Best for: Shopping carts, social feeds, caches
When to Use
Choose strong consistency when:
- Correctness requires latest data (banking, reservations)
- Application cannot tolerate conflicts
- Availability can be sacrificed during failures
Avoid when:
- High availability is critical (user-facing services)
- Geographic distribution creates high latency
- Application can reconcile conflicts semantically