Consistency & Availability Patterns — Core Concepts

Interview Relevance: Critical — Every design decision in a distributed system involves a consistency trade-off. Know the models, know where each applies, and know how to justify your choice.

---

The Core Problem: Distributed State

When data lives on multiple nodes (replicas, shards), they can disagree. A write on Node A may not yet be visible on Node B.

The question is never IF this happens — it always can in distributed systems. The question is what guarantees you offer and what you sacrifice in return.

---

The CAP Theorem (Revisited Deeply)

In the presence of a network partition (P — which is inevitable), you must choose:

The real-world nuance: CAP is a spectrum, not a binary switch. Most modern databases let you tune the consistency level per operation.

Cassandra Consistency Levels (AP → CP spectrum):
  ONE     → fastest, least consistent (any 1 replica replies)
  QUORUM  → majority must agree (N/2 + 1 replicas)
  ALL     → all replicas must agree (strongest, slowest)
  LOCAL_QUORUM → quorum within local DC (good for multi-region)

---

PACELC — The Extension to CAP

CAP only describes behavior during a partition. PACELC also covers the normal case:

---

Consistency Models

From weakest to strongest — each buys you more correctness at the cost of latency/complexity.

Model 1 — Eventual Consistency (Weakest)

All replicas will eventually converge to the same value — but no time guarantee.

✅ Highest availability
✅ Lowest latency (write returns immediately)
✅ Works across geographies (async cross-region replication)
❌ Clients may read stale data
❌ Conflicts possible (concurrent writes to different replicas)
Use: DNS, social media likes/counters, shopping cart, Cassandra defaults

---

Model 2 — Read-Your-Writes Consistency

After a user writes data, their own subsequent reads always reflect that write — even if other users may still see stale data.

✅ User never sees their own writes disappear
✅ Better UX than pure eventual consistency
❌ Routing complexity (sticky sessions or version tracking)
Use: Profile updates, settings changes, social media posts

---

Model 3 — Monotonic Reads

Once a user reads a value at time T, they never read an older value afterward (even if hitting different replicas).

Implementation: Sticky sessions (route user to same replica)
                OR: Read from replica with timestamp ≥ last read timestamp

---

Model 4 — Strong Consistency (Linearizability)

Every read reflects the most recent write, as if there's only one copy of the data.

✅ Clients always see the latest data
✅ No conflicts — all writes totally ordered
❌ Higher write latency (wait for all/quorum replicas)
❌ Unavailable during network partitions (CAP: CP)
Use: Bank balances, inventory counts, distributed locks, leader election

---

Quorum: The Math Behind Strong Consistency

N = Total replicas
W = Write quorum (replicas that must ACK a write)
R = Read quorum (replicas that must respond to a read)

For strong consistency: W + R > N

Example with N=3:
  W=2, R=2 → 2+2=4 > 3 ✅ (at least 1 replica in common → always fresh)
  W=1, R=1 → 1+1=2 < 3 ❌ (eventual consistency — could miss latest write)
  W=3, R=1 → 3+1=4 > 3 ✅ (all replicas written → any read is fresh)

Cassandra tuning:
  QUORUM: W=N/2+1, R=N/2+1 → Strong consistency
  ONE:    W=1, R=1           → Eventual consistency (fastest)

---

Consistency Patterns in Practice

Write Patterns

---

Conflict Resolution (for AP Systems)

When two replicas accept conflicting writes, they must reconcile. Strategies:

---

Choosing a Consistency Level — Decision Guide

---

Worked Example: Consistency in the URL Shortener

Operation	Consistency Need	Choice	Reason
Shorten a URL	Read-Your-Writes	Route creator's immediate reads to primary	Creator must see their new link right away
Redirect (read short code)	Eventual	Cassandra LOCAL_ONE	Stale for 200ms is fine; latency matters more
Delete / Expire a URL	Strong	Cassandra QUORUM	Must not redirect to deleted URLs
Analytics click count	Eventual	Cassandra counter ONE	Approximate count is acceptable
Distributed lock (ID gen)	Strong	ZooKeeper / etcd	Two nodes must not generate the same short code

---

Interview Cheat Sheet

One-Line Summaries

Eventual Consistency:    Will converge — no timing guarantee (DNS, likes, caches)
Read-Your-Writes:        You always see your own writes (profile updates)
Monotonic Reads:         Time only moves forward per client (feeds, counters)
Strong Consistency:      Latest write always visible (payments, locks)
Linearizability:         Strongest — real-time total order of all operations
CAP (partition):         Choose CP (correct but unavailable) or AP (available but stale)
PACELC (normal):         Choose latency (L) or consistency (C) in steady state
Quorum (W+R > N):        Math that gives strong consistency with replicated systems
CRDT:                    Conflict-free data structures (counters, sets, flags)

The Interview Phrase

"The redirect path is extremely read-heavy and latency-sensitive,
 so I'd use eventual consistency — Cassandra LOCAL_ONE — accepting
 200ms of potential staleness for maximum speed. The URL deletion
 path needs strong consistency (QUORUM) so we never redirect to
 a deleted URL. For the creator seeing their own new short link,
 I'd implement read-your-writes by routing their immediate GET to
 the primary for 5 seconds after creation. This lets us maximize
 performance on the hot read path while maintaining correctness
 where it actually matters."

---

Red Flags vs. Green Flags

🔴 Red Flag	🟢 Green Flag
"Use strong consistency everywhere"	Tune per operation — not all data needs the same guarantee
"Eventual consistency means data can be wrong"	Eventual = will converge; "stale" not "wrong"
Ignore replication lag impact on UX	Describe read-your-writes for post-write reads
Forget quorum math	W + R > N gives strong consistency — state this explicitly
Say "CAP means choose 2 of 3"	Clarify: P is mandatory in distributed systems; choose between C and A
No conflict resolution strategy for AP systems	Always explain LWW, MVCC, or CRDT for eventual consistency systems

IMPORTANT

Never say "I'll use eventual consistency" without explaining what happens during the inconsistency window and why that's acceptable for this specific operation. The interviewer is testing whether you understand the implications.

TIP

Bringing up PACELC (not just CAP) is a strong senior signal — it shows you understand consistency trade-offs in normal operation, not just during failure scenarios.