Like Button at Scale

Eventual consistency, but the liker sees their own write. Counts are approximate by design; hot keys are the real enemy.

SavedSaved on this device

The problem

Eventual consistency, but the liker sees their own write. Counts are approximate by design; hot keys are the real enemy.

Build the like button for a social product at scale: every post, video, story, and tweet carries a heart. A user taps it once to like, taps again to un-like; everyone else sees a count that updates in near-real-time. The system is read-dominated by 100–500×, hot-keyed on viral posts, must give the liker read-your-write on their own heart, and accepts approximate counts everywhere else.

The interview answer ("one Redis INCR, one Postgres row, done") survives ~10K writes/s and 100K reads/s on a single non-viral product. We're sizing for 2B likes/day with single-key viral peaks at 50K writes/s and read amplification 100–500×, and we have to defend it at 3am when Ronaldo posts.

Reading: TAO: Facebook's Distributed Data Store for the Social Graph (USENIX ATC 2013) · Scaling Memcache at Facebook (NSDI 2013) · How Discord Stores Trillions of Messages (Discord Eng blog, 2023) · Twitter — The Infrastructure Behind Twitter: Scale (Twitter Eng blog) · PSY's Gangnam Style 32-bit overflow incident (2014) · Pinterest Flink Counter Framework (Current 2025) · Google SRE Workbook ch.5 — Alerting on SLOs (burn-rate alerts)

counter sharding
hot key absorption
outbox + event-sourced fanout
CRDT G-counters
read-your-write under eventual consistency
idempotency + dedup
async anti-abuse

01Clarifications

What would you ask before drawing a single box?

Ambiguity you would resolve with the interviewer: scope, scale, who uses it, what counts as done.

About Like Button at Scale

Eventual consistency, but the liker sees their own write. Counts are approximate by design; hot keys are the real enemy.

Difficulty: intermediate
Time: about 45 minutes
Stages: 10
Topic: Feeds, Timelines, Counters & Ranking

How this problem is worked

Ten stages, from the questions you would ask an interviewer to the trade-offs you would defend. Each asks one question, and the simulator runs the architecture you draw against the requirements you wrote.

01ClarificationsWhat would you ask before drawing a single box?
02Functional reqsWhat must this system actually do?
03Non-functionalWhat must it promise about speed, uptime and correctness?
04Capacity estimationHow much load and data does this have to hold?
05API designWhat does the outside world call, and what comes back?
06Data modelWhat gets stored, and what is it looked up by?
07Use-case breakdownHow does each requirement actually get served?
08High-level designWhich components handle a request, and in what order?
09Deep divesWhich part breaks first, and what do you do about it?
10Trade-offsWhat did this design cost, and what breaks at 10×?

Primary sources for this problem

TAO: Facebook's Distributed Data Store for the Social Graph (USENIX ATC 2013)
Scaling Memcache at Facebook (NSDI 2013)
How Discord Stores Trillions of Messages (Discord Eng blog, 2023)
Twitter — The Infrastructure Behind Twitter: Scale (Twitter Eng blog)
PSY's Gangnam Style 32-bit overflow incident (2014)
Pinterest Flink Counter Framework (Current 2025)
Google SRE Workbook ch.5 — Alerting on SLOs (burn-rate alerts)

More in Feeds, Timelines, Counters & Ranking

What to show and in what order: fanout on write versus read, hot/top/new scoring, approximate counters, trending, and recommendation.

Browse the full problem catalog, or see what the simulator does and does not model.