Section 7: Where Writers and Readers Actually Feel It - Deep Dive (Candidate-Driven)

Executive Summary: The interviewer hands you the wheel, and where you steer is scored. We dive into three places users feel directly: autosave, which must never lose Maya's words when her phone and laptop disagree; the feed, which must survive a 5-million-follower publication; and the counters, which must not turn a viral post into a hot row.

The interviewer caps the marker: "Where would you like to go deeper?" Answer with a plan:

"The publish pipeline is the hardest subsystem, so I'd give it its own pass next. First, three places users feel directly: autosave, because it's 450 writes per publish and the one place we can lose someone's work; the feed, because one giant publication breaks naive fan-out; and claps and views, because a viral post turns a counter into a hot row."

Key Insight: Every dive lands in three beats: the mechanism (how it works), the number (what it costs or protects), and the trade-off (what you gave up, and what would make you change your mind).

Dive One: Autosave and the Two-Device Conflict

The editor saves 2 s after typing pauses, and at least every 10 s during continuous typing (a debounce with a 10 s max-wait), averaging about 3 saves a minute. Maya's post takes 540 autosaves over three evenings; cluster-wide that's **1,560/s at peak**, each acked within the 300 ms p95 SLO. Every save is the full document plus the version the client last saw:

PUT /v1/posts/a81f3c9e2b7d/draft
If-Match: "311"
{ doc, clientSaveId }

The path carries the random public ID; the editor translates it once to the 64-bit time-ordered post_id that keys the store. The save becomes one single-partition compare-and-set:

UpdateItem drafts  key: post_id = <internal id of a81f3c9e2b7d>
  SET body_zstd = :doc, draft_version = draft_version + :one,
      updated_by_device = :device, last_save_id = :clientSaveId
  ConditionExpression: draft_version = :v

No lock, no cross-partition work. Three details make it safe:

• clientSaveId makes retries idempotent. If an ack is lost and the client retries with If-Match: "311", the server sees version 312 carrying that same save ID and returns 200 {draftVersion: 312}, not a false conflict.
• Fast-forward, not overwrite. A 412 carries {currentVersion, updatedAt, deviceLabel, lastSaveId}. If lastSaveId is one of this device's own acknowledged saves, the server is merely behind it (the region-failover case), so the client re-saves with If-Match: <currentVersion>, no dialog. Any other lastSaveId means someone else wrote, and that gets the conflict dialog. Comparing bare versions isn't safe, because a failover can reuse version numbers.
• Words never depend on the network. Edits land in IndexedDB first. An ack marks them synced but doesn't delete them: the device keeps its latest acknowledged version and recent save IDs for several minutes, longer than the 1-minute cross-region RPO. A tunnel, dead Wi-Fi, a 412 or a failover all leave the text on the device.

Every 5 minutes of active editing, the editor also writes a checkpoint revision to object storage (3M a day), which feeds revision history and restore.

Now the conflict. Maya edits on her phone on the streetcar at version 311, loses signal, keeps typing. At home her laptop advances the draft to 315. Then the phone reconnects.

The lastSaveId is the laptop's, so this is a real conflict. The phone shows "This draft was edited on your MacBook at 9:42 p.m.", files its copy as a checkpoint (POST …/revisions, reason: "conflict"), fetches the laptop's version (GET …/draft), and Maya picks; keeping hers is a PUT with If-Match: "315". Both versions survive.

The Pushback: "Why not just last-write-wins?"

"Because a draft is one person's whole document, and LWW throws one side away whole. If arrival order wins, the phone overwrites the laptop's acknowledged saves 312 to 315, breaking our promise that an acknowledged autosave is never lost. If timestamps win, twenty minutes of streetcar edits vanish. Conflicts are rare, so a dialog is cheap."

The follow-up: "Then why not a CRDT, so both sides merge?"

"We're single-author, so a merge engine buys almost nothing and costs an op log, replay and tombstones. Full-document saves are 20 KB at 520/s, about 10 MB/s, and every save heals the draft completely. The flip trigger is real-time co-editing; then it's a Yjs-style CRDT behind a document server, which Section 11, Follow-up Feature Evolution, covers."

Quick check before moving on: