Lesson 15: Consistency Models

Roadmap

You are in System Design Interview Prep, Track 01, Core Fundamentals: lesson 15 of 19 (linearizable vs causal vs eventual, and session guarantees). It builds on Lesson 14: PACELC Theorem. Next comes Lesson 16: Fault Tolerance.

These are the written notes for the lesson's video. Prefer paper? The same notes are a free, printable PDF: download SD-A-015.pdf.

Concept

Explanation

The spectrum

Figure 1. Stronger models are easier to reason about but need coordination; weaker ones are cheaper and stay available.

Session guarantees

Between the extremes, session guarantees protect a single user's experience:

• Read-your-writes: you always see your own changes.
• Monotonic reads: once you've seen a newer value, you never see an older one again.
• Monotonic writes: your writes are applied in the order you made them.
• Writes-follow-reads: a reply you write is ordered after the post you read.

Why read-your-writes matters

Figure 2. The write goes to the primary, the reload reads a lagging replica, and the author sees the old value.

Key terms

Code

Pick the model per operation, not per system. The question is always: what does it cost if this read is stale, or these two events are seen out of order? A balance read before a withdrawal needs the latest value; a review count can lag; a chat thread needs causal order but not global freshness.

The second technique from the example above, read-your-writes on PostgreSQL replicas, fits in a few lines: remember where in the log the user's last write ended, and read from a replica only if it has replayed that far.

from sqlalchemy import create_engine, text

primary = create_engine("postgresql+psycopg://postgres:devpass@localhost:5432/shop")
replica = create_engine("postgresql+psycopg://postgres:devpass@localhost:5433/shop")
last_write_lsn: dict[int, str] = {}  # per user; in production, keep it in the session

def save_bio(uid: int, bio: str) -> None:
    with primary.begin() as c:
        c.execute(text("UPDATE profiles SET bio = :b WHERE id = :i"), {"b": bio, "i": uid})
    # Read the log position after COMMIT, so it includes the commit itself.
    with primary.connect() as c:
        last_write_lsn[uid] = c.execute(text("SELECT pg_current_wal_lsn()::text")).scalar_one()

def read_bio(uid: int) -> str:
    query = text("SELECT bio FROM profiles WHERE id = :i")
    lsn = last_write_lsn.get(uid)
    with replica.connect() as c:
        caught_up = lsn is None or c.execute(
            text("SELECT pg_last_wal_replay_lsn() >= CAST(:l AS pg_lsn)"), {"l": lsn}
        ).scalar_one()
        if caught_up:
            return c.execute(query, {"i": uid}).scalar_one()
    with primary.connect() as c:  # this replica is behind the user's own write
        return c.execute(query, {"i": uid}).scalar_one()

Only the user who just wrote is ever sent to the primary; everyone else keeps reading the replica.

Practice

1. Pick a model per operation

For an online store, say whether each operation needs strong, causal or eventual consistency, with one sentence why: (a) checking that a coupon code is still valid before applying it; (b) the "142 people bought this" badge; (c) the chat thread between buyer and seller; (d) reserving the last unit in stock at checkout; (e) the seller's average star rating.

2. Watch read-your-writes work

On a primary + streaming replica pair (the two-container setup in Backend Track 04, Module 08 is enough), create profiles (id INT PRIMARY KEY, bio TEXT) with one row on the primary. Freeze the replica with SELECT pg_wal_replay_pause(); (run on the replica; it keeps answering queries but stops applying changes). Call save_bio, then read_bio, and also query the replica directly. Then run SELECT pg_wal_replay_resume(); and call read_bio again.

3. Diagnose: the vanishing signup

A user reports: "I created my account, landed on my dashboard, and it said user not found. When I refreshed, I was there." Signup writes the user row on the primary and returns 201; the dashboard immediately calls GET /me, which the team recently "optimized" to read from a replica. What is the cause, and what are two correct fixes?

Project

Design the consistency strategy for seat selection in a concert-ticketing system: users browse a live seat map, see "12 seats left in this section", place a temporary hold on seats during checkout, and buy. For each of those four operations, state the consistency model, how much staleness it tolerates, and what a user would see go wrong if you chose a weaker model for the operations that need a strong one. No solution is given. (Hint: the line between strong and eventual is the claim, not the browse.)

Interview questions

Each question is tagged by kind: Basic (definitions), Scenario (apply it to a system) and Tricky (the follow-ups interviewers use to go deeper). Answer out loud before you open the answer.

Common mistakes & troubleshooting

• Treating consistency as a yes/no choice.
• Using eventual consistency for data the author just edited.
• Load balancing reads across replicas so a user sees values jump back and forth.
• Paying for linearizability where causal or eventual is enough.
• Picking one model for the whole system. Different data tolerates different staleness; decide per operation and write down why.

Further reading & sources

• Jepsen: Consistency Models - a precise map of the models on this page, from strict serializable and linearizable down to session guarantees.
• Designing Data-Intensive Applications (Martin Kleppmann) - its replication and consistency chapters cover replication lag, read-your-writes, monotonic reads and linearizability in depth.
• PostgreSQL: System administration functions - pg_current_wal_lsn, pg_last_wal_replay_lsn and pg_wal_replay_pause, used in the code and practice above.

Free PDF notes

Download these notes as a printable PDF, with every diagram: SD-A-015.pdf. All Phase 1 notes in one file: Phase 1, Core Fundamentals (PDF).

Next

Continue with Lesson 16: Fault Tolerance.