Functional Requirements

1. Users should be able to like and unlike an item, and retries or duplicates must never change the count.
2. Users should see an item's like count. It may lag a few seconds, but it must say so.
3. The acting user should see their own like instantly, and it is always right.
4. Users should be able to list who liked an item (paginated), and account deletion must erase likes with the public count dropping honestly.

Below the line (out of scope):

• Deciding which likes are fake. The abuse system owns that; this design gives it a retraction path through the same write path users take.
• Ranking, trending, and notifications. They consume the same stream this design produces; worth one sentence if asked.
• Reaction types beyond like/unlike. Same machinery, more edge states.

Non-Functional Requirements

1. The edge is exact. Retries, duplicates, crashes, and replays never change what the count converges to.
2. The count is eventually consistent with a stated bound: staleness p99 under 5 seconds, measured at the sink from event time, not guessed, and labeled asOf.
3. Like-write availability 99.95%, p99 under 150ms. Under overload, fail writes fast with retry-after rather than queueing them; reads keep serving.
4. Read-your-writes for the actor (their own button), eventual for everyone else.

Defining the Core Entities

• LikeEdge is one row per (item, user). It has a state, LIKED or UNLIKED, instead of being created and deleted; this row is the truth. Each real flip bumps a per-row version number (op_id) atomically in the same write. The row key is item + hash(user) % 64, so one item's rows spread over 64 partitions.
• Count is one number per item, computed FROM the edges. Derived, never the truth. The counter row also remembers last_window, the newest second it has applied; that field is the dedupe fence.
• IdempotencyRecord maps (user, request key) to the stored answer for about a day, so a retried request replays its first answer.
• RetractionProposal is the abuse hook: the abuse system flips edges through the same conditional-write path as users, so retracting fake likes needs no special machinery.

API or System Interface

POST   /v1/items/{itemId}/likes            // Idempotency-Key: one key per tap, kept across retries
DELETE /v1/items/{itemId}/likes/{userId}   // same key rules; userId must match the session
  → 200 either way                        // liking twice, or unliking nothing, is fine by design
GET    /v1/items/{itemId}/count            // → { count, asOf } - approximate, labeled
GET    /v1/items/{itemId}/likes/{userId}   // → { liked } - read-your-writes for the actor, else eventual
GET    /v1/items/{itemId}/likes?cursor=&limit=   // who liked, paginated
POST   /v1/likes:batchGet   { itemIds: [...] }   // feed pages: N counts + N button states in one call

• The acting user comes from the login session, never from the request body.
• Same key + same request means the server replays its first answer and changes nothing.
• Why 200 on a no-op: like and unlike are target states, not events. Asking again for a state you already have is harmless, which is exactly what makes retries safe.
• The button read is honest about its guarantee: read-your-writes for the actor via the session overlay, eventual for anyone else looking at the same row.

1) Users can like and unlike, and retries never change the count

• A like is one conditional write on its edge row, which is the source of truth: set LIKED only if currently UNLIKED (or the row is new). A retry finds the state already LIKED, changes nothing, and still gets its 200.
• The database enforces one row per (item, user), so a second like can update that row but never create a second one.
• The request key closes the gap state checks cannot: the service keeps (user, key) → answer for about a day and replays the stored answer. Deep dive 1 walks the exact failure this exists for.
• On every successful like, the service also writes a small per-user session cache entry ("you liked X just now"), which is what makes the actor's own button instant in HLD-3.
• The gateway owns auth and rate limits, and is where the abuse system's retraction proposals enter, using the same write path as users.

2) Users see a count that lags seconds, and says so

• Why streaming at all: at 5B events a day the count cannot be computed per read; something must maintain it. The same stream is what the abuse and trending systems will feed on.
• The edge database publishes every committed row change, in order per row (DynamoDB Streams, NEW_AND_OLD_IMAGES). A small relay, the tailer, tails that change feed and produces each committed flip into Kafka; the stream's 24h retention bounds how long the tailer may be down.
• Events land in Kafka keyed item#hash(user)%64, the same deterministic rule everywhere. Deterministic matters: a retried event lands in the same group and meets the duplicate-check that already saw it. A random spread would dodge it and double-count.
• Stage 1: dedupe workers partitioned by bucket key; for one viral item's traffic, its 64 bucket keys land on 64 dedupe workers, each remembering the last op_id applied per edge. An event at or below that number has been seen: drop it. This memory only covers the 7-day replay window, not all 10¹¹ edges; reconciliation is the backstop beyond it.
• Stage 2, and it must be SAID as a stage: a keyBy(item) shuffle brings all 64 buckets' deltas for an item back together at one window subtask, which adds them up one second at a time and emits ONE (item, second, +N): "+8,214" instead of 8,214 writes.
• Why the regroup is stated: without it, 64 workers each write partial windows, and any per-item guard at the sink accepts the first partial and wrongly rejects the other 63. That is a 63/64 undercount on exactly the viral case.
• The counter row itself carries the fence: ADD the total and SET last_window, but only if this second is newer. One atomic statement; a replayed second fails the condition and does nothing. Deep dive 3 stress-tests this.

3) The actor sees their own like instantly

• Two separate read paths, and they never mix.
• The count, cheap: page loads read CDN cache (a few seconds of TTL) → count service → Redis → counter store. Most reads never reach a database.
• Two standard brakes against the viral-item stampede when caches expire together: serve the stale copy while refreshing, and let only one refresh per item through at a time.
• The own button, exact: button state is the session-cache overlay layered over an ordinary edge read, so the tapping user sees the flip instantly even while the public count lags.
• Feed pages make one collection-level batch call, POST /v1/likes:batchGet with the page's item ids, that returns N counts plus N button states together.

4) Who liked an item, and erasure that drops the count honestly

• The bucket key earns its place here and in deep dive 2: a single partition takes about 1K writes/s, and the viral item does ~17K/s. Without buckets the source of truth melts first and nothing downstream matters.
• What the bucket costs: "show me every liker of this item" now has to ask all 64 buckets. Acceptable, because that full 64-bucket fan-out stays an admin and recount path, not a user path. The user-facing who-liked page is not free either: a page of likers has no single-bucket home, so serving one page still means a multi-bucket read, a cost this design accepts out loud.
• Erasure: deleting an account hard-deletes its edge rows AND its retry-protection rows. Each deletion flows through the pipeline as a minus-one, so counts drop honestly and publicly.
• Celebrity-scale deletion (50M unlikes) is just a big polite user: ordinary minus-ones, spread across buckets, rate-limited. No special path.
• Stream retention (7 days) is shorter than the 30-day erasure window, so a rebuild replay can never re-materialize erased data.

• If they just nod and wait: "the riskiest part is making the count exactly right under retries, shall I open that?"
• Running behind: protect dives 1 and 3. Cut dive 5 (regions) first.

1) How do retries and duplicates never change the count?

• The trap has three layers, and each protects against a different failure. The one that kills naive designs: a like's 200 is lost, the user unlikes, and the client retries the OLD like.

2) One post goes viral. What melts first?

• Steelman the simpler design first: edge store + a per-event ADD on the counter row with op_id as the dedupe token, no Kafka, no stream processor. That is where to start at small scale, and honesty about where it breaks is the point: a storage partition caps near 1K writes/s, so it breaks at the first modestly viral event, not the mega-viral one.

3) Exactly once: crash the processor mid-window and tell me the count

• This is the probe the whole design exists to survive. The answer must locate the guarantee at the LAST write, not in the stream.

UPDATE counter SET
  count = count + :n,
  last_window = :w
CONDITION last_window < :w
-- one atomic statement; a replayed window fails the condition and does nothing

4) The counter store dies. Counts drift. A celebrity deletes their account.

• Three separate repair scenarios, each self-contained, all leaning on one property: the counter is derived, so it can always be rebuilt from the edges.

5) Multi-region, honestly

• The commitment must be stated before the failover story: who is allowed to write an edge, and what happens to that authority when a region dies mid-write.

6) How do you run it? SLOs, alerts, backpressure, and the cutover

• Targets: like-write availability 99.95% with p99 under 150ms; count staleness p99 under 5s, measured as watermark lag from event time at the sink, not inferred.
• Alerts map one-to-one to those targets: sink watermark lag (staleness burning), consumer lag, per-bucket write throttles (the hot-item armor is breached), reconciliation mismatch (any nonzero pages), retry-protection error rate.
• When overloaded: fail like-writes fast with retry-after, never queue them; reads keep serving. Counts go visibly stale rather than wrong, and own-buttons stay correct via the session overlay. The degradation order is a choice, and this one keeps every promise the requirements made.
• Rolling out a new pipeline: run old and new side by side in shadow and diff daily; cut over at a marked stream position by initializing each counter's fence there, so the new pipeline's replays bounce and the old one's tail cannot double-apply. Rollback is the same move at another mark. This is the dedupe-regime switch done on a live counter without double-counting.
• Runbook heads: counter rebuild (recount + bounded replay), pin move (epoch increment as step one), bucket-count growth for a melting keyspace.

Final Design

• A like is one conditional write on its edge row, the source of truth, with the request key replaying lost answers and the session overlay making the actor's button instant.
• The change feed streams every committed flip into Kafka keyed item#hash(user)%64. Stage 1 drops duplicates per bucket; the keyBy(item) shuffle brings an item's deltas to one window subtask; it emits one (item, second, +N).
• The counter row's fence (ADD + SET last_window, CONDITION last_window < :w) makes every replay a no-op. The guarantee lives at the last write.
• Product pages read through CDN, count service, and Redis; the count is labeled asOf and may lag seconds. The two read paths never mix.
• Reconciliation recounts from a snapshot and heals through the same pipeline as its own fenced window. Erasure flows as rate-limited minus-ones. Region moves bump the range epoch first so stragglers fail closed.

What is Expected at Each Level

• Mid-level candidates are expected to state the edge/count split, get one row per (item, user) with a conditional write, cache the read path, and know the count is maintained by a pipeline rather than computed per read.
• Senior candidates are expected to carry idempotency through all three layers (including the stale-retry-after-unlike hole the request key closes), state the two-stage stream topology with deterministic keying and explain the 63/64 undercount the missing shuffle would cause, put the fence on the counter row itself, bucket the truth store with the cost named, and give the bounded rebuild story (edge recount plus 7-day replay).
• Staff candidates are expected to interrogate the requirements before designing (counting vs integrity, erasure as a visible product decision), do the scale math that finds the viral item's 17K/s against the 1K/s partition cap, steelman the simpler design and name its real breakpoint, let the $400K/month write bill pressure build-vs-buy, bring the operations story unprompted (SLOs measured not inferred, alerts mapped to them, a degradation order that keeps the requirements' promises, the shadow cutover that switches dedupe regimes safely), fence the region move with epochs and admit where the epoch's storage is still an open choice, and show restraint: present requirements through high-level design in about 20 minutes and let the interviewer pick the deep dives.