Section 8: The Heart That Never Lies - Deep Dive: Idempotency, Unlike & Read-Your-Own-Write
Executive Summary: Section 7 defended the counter against volume; this section defends it against sequence — the double-taps, retries, and unlike races that corrupt counts one user at a time. We replay Priya's entire subway ride as a correctness audit and show that every threat dies against machinery already built: the conditional insert from Section 5, the state-setting verbs from Section 4. Then we face the deepest question in the module — "I liked it, why does the count look the same?" — and answer it not with stronger consistency but with composition at the display layer, the session-consistency move that separates Staff candidates from everyone still reaching for linearizability.
The interviewer erases nothing from the board. Instead, they pick up Priya's story from Section 1 and read it back like a prosecutor: "Your user double-taps @astra's post on the subway. The network drops her response and the client retries. She unlikes it mid-argument, then re-likes it. Walk me through every write — and tell me what the counter says at the end." This is an audit of the design you already shipped, and it is where the Dismissal archetype dies in public: UPDATE posts SET like_count = like_count + 1 turns this one ride into three phantom likes and an inverted toggle. Your job is to show the boring baseline absorbing the chaos without a single line of special-case code.
Priya's Ride, Replayed as a Correctness Audit
Four events, four threats, and — because Sections 4 and 5 did their jobs — four clean outcomes:
| Event | The threat | The mechanism that absorbs it | Final state |
|---|---|---|---|
| Double-tap | Two inserts, count +2 | Conditional insert: second write finds the row exists, fails cleanly, no increment (Section 5) | Liked, +1 |
| Dead-zone retry | Replayed request re-applies the action | PUT /posts/{postId}/like declares a state, not an action; the retry is a verbatim no-op (Section 4) |
Liked, +1 |
| Unlike | Decrement races the earlier like | Conditional delete: succeeds only if the row exists, decrements exactly once | Not liked, net 0 |
| Re-like | Two in-flight ops interleave | The ledger's conditional writes serialize them; the last state to land wins | Liked, +1 |
Section 4 already retired the toggle — a retried PUT is a no-op by declaration, where a retried toggle inverts intent — so the audit here starts at the storage engine.
The unlike-then-relike race deserves one more beat, because it echoes a defense this course has made before — the Color Picker module spent a deep dive proving when last-write-wins is correct. Same shape here: Priya's unlike and re-like are total statements of one person's latest intent about one edge. There is nothing to merge; if the re-like lands last, liked is the right answer by definition. Recency is the business rule. The ledger's conditional writes give each operation a clean serialization point, and the final row state — present or absent — is the truth.
Key Insight: Notice what the audit did not require — no deduplication service, no request-ID tracking, no application-level mutex. The uniqueness constraint on (post_id, user_id) plus state-setting verbs means idempotency is enforced by the storage engine and the HTTP semantics, not by code you had to remember to write. Correctness you don't implement is correctness that can't regress.
The whole lifecycle fits in one picture — note that every arrow either changes state exactly once or is a self-loop no-op:
Sign in to continue reading
The rest of this lesson is available with a free account. Signing in with Google or Microsoft is free.
Sign in to read the full lesson