#36Like Button at Scale
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