Consistency Models: The Interview Topic That Exposes Weak System Design

Consistency is a choice, not a default. In distributed systems you can’t have everything: the CAP theorem forces trade-offs between Consistency, Availability, and Partition Tolerance. Which consistency model you pick should be driven by product requirements, not by what’s easiest to implement.

Quick definitions

• Strong consistency — A read always returns the latest write. This simplifies reasoning about correctness but usually increases latency and can reduce availability during partitions.
• Eventual consistency — Replicas will converge to the same state eventually. Reads are fast and highly available, but they may be stale and can cause conflicts that require reconciliation.
• Causal consistency — Operations that are causally related are seen in the same order by all nodes. Independent operations may be seen in different orders. It sits between strong and eventual in terms of guarantees and cost.
• Read-your-writes — A client always sees its own updates. This improves user experience for session-scoped operations without requiring global strong consistency.

Trade-offs to keep in mind

• Latency vs. consistency: Strong consistency often requires coordination (leader election, quorums), adding latency. Eventual consistency favors low latency.
• Availability under partition: If you must remain available in partitions, you may need to relax consistency.
• Complexity: Strong guarantees simplify reasoning but add implementation complexity and operational overhead. Eventual consistency requires conflict handling (CRDTs, application-level reconciliation).
• Conflict handling: Eventual models rely on strategies such as last-writer-wins, application merges, or CRDTs.

Implementation patterns

• Leader-based replication (primary-secondary) — often used to provide stronger guarantees via a single source of truth.
• Quorum reads/writes — configure read and write quorum sizes to balance consistency and availability.
• Vector clocks / version vectors — detect concurrent updates for reconciliation.
• CRDTs — built-in convergence without coordination for certain data types.
• MVCC — supports snapshot/strong reads while allowing concurrent writes.

How to answer this in an interview

1. Ask clarifying questions: What are SLAs for latency? What are the acceptable staleness and outage behaviors? What are the critical failure modes?
2. Map product needs to models:
   • Financial transactions, inventory systems → prefer strong consistency.
   • Social feeds, caching, analytics → eventual consistency is usually fine.
   • Collaborative editors or activity streams with causal ordering → causal or hybrid approaches.
   • User sessions and profile updates → read-your-writes for better UX.
3. Propose an implementation and justify trade-offs: e.g., “We’ll use leader-based replication for account balance updates (strong) and eventual replication for analytics, using CRDTs for counters.”
4. Mention fallback plans: how the system behaves in partitions and how to recover or reconcile.

Short sample answer you can give

"We should pick consistency based on product needs. If correctness is critical (banking), use strong consistency with leader-based replication or quorum rules. If availability and low latency matter more (social feed), choose eventual consistency and use mechanisms like CRDTs or application reconciliation. For session-focused operations, enforce read-your-writes. I’d clarify SLAs and failure modes, then pick an architecture and explain how it meets those guarantees."

One-line checklist for interviews

• Ask about latency SLOs, staleness tolerance, and critical failure modes.
• Map data types to consistency models.
• Explain concrete replication or quorum strategies.
• Discuss conflict resolution and recovery.

Consistency model choices reveal deep design thinking. Don’t try to memorize a “best” model — justify your choice by product requirements, trade-offs, and a concrete implementation plan.