System Design · Architecture under constraints
What consistency models should you know and when do they matter?
Short answer
Consistency models range from linearizability to eventual consistency. Weaker models allow stale or reordered reads but improve latency and availability; choose per operation based on user-visible harm.
A consistency model defines which values a read may return after writes. It is a contract between the storage system and the application. The strongest model is expensive because it requires coordination; the weakest is cheap but pushes complexity into the product.
The spectrum
- Linearizability: every operation appears to take effect at a single point in time, respecting real-time order
- Sequential consistency: all clients see the same order of operations, but that order may differ from real time
- Causal consistency: operations that are causally related are seen in order by everyone
- Read-your-writes: a client sees its own completed writes
- Monotonic reads: a client never moves backward to an older value
- Eventual consistency: replicas converge if writes stop, with no bound on when
Session guarantees are practical compromises. Read-your-writes and monotonic reads are client-centric: they do not require global coordination, only routing or version tracking for one session. A user editing a profile needs read-your-writes; a global inventory counter needs something much stronger because overselling is unacceptable.
Weaker consistency is not automatically wrong. A like count, a view counter or a recommendation list can tolerate staleness. An account balance, a unique username claim or a seat reservation usually cannot. The design work is to identify which reads can be stale and route only those to replicas or caches.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1What is the difference between linearizability and sequential consistency?
- 2How do you implement read-your-writes without routing everything to the leader?
- 3When is causal consistency enough?
- 4How do you resolve conflicting writes in an eventually consistent store?
Say it in the interview
Consistency models describe what a read is allowed to see, from linearizability down to eventual consistency. Strong models need coordination and cost latency or availability, so I choose per operation. Session guarantees like read-your-writes and monotonic reads handle many user-facing problems without global coordination. For weaker models I always specify conflict resolution and what stale data means to the user.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live System Design mock interview and get scored feedback on depth, clarity and confidence.