Preview — Pro guide
You are seeing a portion of this guide. Sign in and upgrade to unlock the full article, quizzes, and interview answers.
Sections
Related Guides
Databases: Sharding, Indexing & Replication
High-Level Design
Distributed Systems Patterns
High-Level Design
Distributed Locks: Redlock, ZooKeeper, Fencing Tokens & Exactly-Once Guarantees
High-Level Design
Caching: Strategy, Redis Internals & Distributed Patterns
High-Level Design
Message Queues & Streaming: Kafka, Delivery Semantics, and Consumer Groups
High-Level Design
Consistency Models: Strong vs Eventual vs Causal, Linearizability, CRDTs & CAP Theorem
Consistency models define what values a distributed read can return after a write. Master linearizability (strong consistency), sequential consistency, causal consistency, eventual consistency, and read-your-writes — with practical implications for database selection, microservice design, and the CAP theorem's real-world limitations.
Why Consistency Models Are Tested at Staff Level
"Use eventual consistency" is one of the most overused and under-understood recommendations in system design interviews. Candidates say it without knowing what guarantees it provides, what problems it introduces, or when a stronger model is required.
Consistency models define a contract: after a write completes, what value will a subsequent read return? The answer depends on the model. Getting this wrong in production causes: showing a user a deleted post that reappears, a bank account that briefly shows the wrong balance, or two nodes in a cluster both believing they are the leader.
This topic distinguishes candidates who have worked with distributed systems in production from those who have only designed them on whiteboards.