Design a likes counter

Design the heart button on a photo-sharing app: tap to like, tap again to unlike, and a count under every photo. It sounds like count = count + 1. At 200,000 taps a second, with one photo going viral and every feed page showing 30 counts, it becomes a lesson in where the truth lives, how to count without locking, and how exact a number really needs to be.

1. The prompt

"Design the like button and like counts for a photo-sharing app with hundreds of millions of users."

What makes it hard:

• A toggle, not a counter. Like, unlike, like again, double taps, retries on a bad network: the count must still match the number of people who currently like the photo.
• One very hot photo. A celebrity post can take 50,000 likes a second, all aimed at a single number.
• Reads dwarf writes. Every photo in every feed shows a count, so counts are read far more often than they change.

2. Frame the problem

3. What it must do

1. Like and unlike a photo; repeated taps and retries change nothing extra.
2. Show counts for every photo on screen, and whether you liked each one.
3. List who liked a photo, newest first.

Not now: other reactions (the same design with a reaction type), notifications to the owner (the notification system, D05), ranking feeds by likes (D06).

4. How well it must do it

5. Numbers that change the design

Illustrative numbers.

6. The nouns

• Like: one row per (photo, user) that currently likes it. This is the truth.
• Count: the number of like rows for a photo. Derived, cached, and always recomputable.
• Like event: "user U liked (or unliked) photo P at time T", produced only when the like row actually changed.

likes_by_photo  (photo_id, user_id) → liked_at                 (partition by photo; list likers newest first)
likes_by_user   (user_id, photo_id) → liked_at                 (partition by user; "did I like these 30?")
photo_counts    (photo_id, shard 0..N) → count                 (N = 1 for most photos; more when hot)
count_cache     photo_id → count, as_of                        (Redis)

7. The contract

PUT    /v1/photos/{id}/like      → 200 {liked: true}    (idempotent: liking twice is still one like)
DELETE /v1/photos/{id}/like      → 200 {liked: false}
GET    /v1/photos/likes?ids=…    → [{photo_id, count, liked_by_me}]   (up to 50 per call)
GET    /v1/photos/{id}/likers?cursor=…  → users, next cursor

PUT and DELETE describe the state the user wants, not a change, so a retry after a timeout can't double-count; that is better than an idempotency key here. The user comes from the token.

8. First working version

A likes service writes the like row and, only if it changed, emits a like event. A counter consumes events and updates counts in batches. Feeds read counts from a cache in front of the count table.

8.1 Tapping the heart

8.2 Showing 30 counts on a feed page

9. Make it hold up

9.1 Double taps, retries and the toggle data safety

The rule that fixes it: the count changes only when the like row changes, and by exactly that change. INSERT … ON CONFLICT DO NOTHING (or a conditional put in a key-value store) tells you whether a row was created; DELETE tells you whether one was removed. Emit +1 or −1 from that answer, never from the request.

9.2 Counting without locking speed

The counter must not double-apply a batch after a crash: it stores the stream offset in the same transaction as the counts (or keeps per-photo "last applied offset"), so a replay skips what was already counted (Module 18).

9.3 The viral photo load shape

Most photos never need this, so split counters are turned on per photo when its like rate crosses a threshold, and the count cache absorbs the reads: one cached value per photo, refreshed every second or two, with requests for the same key collapsed into one fetch (Module 09). The lab in section 13 shows how batching and splitting interact.

9.4 Counts that drift, and how to repair them data safety

However careful the pipeline, counts drift: a lost event, a bug in an old app version, likes removed by the spam team, an account deletion. Because every like is a row, the count can always be recomputed. A reconciler recounts photos that changed in the last day (cheap: only active photos) and writes corrections as ordinary events; a monthly sweep checks a sample of everything else. Alert when corrections exceed 0.1%: that means a bug, not noise.

9.5 Bought likes security

• Rate limits per account and per device (Design D02): a human can't like 300 photos a minute.
• Scoring new and suspicious accounts; their likes count for the owner's eyes but may be held back from ranking until trusted.
• Removal in bulk: when a bot network is found, its like rows are deleted and the deletions flow through the same event path, so counts fall back automatically.

9.6 The whole design after the deep dives

10. Interviewer follow-ups

11. When things break

12. Wrap-up and the clock

Trade-offs we made:

• Like rows as the truth, counts derived: more storage, but every count can be repaired.
• Counts seconds behind for others, instant for the tapper.
• Batching per photo and split counters only for hot photos.
• PUT/DELETE of a state instead of "add one", so retries are harmless.

What we'd watch: counter lag · cache hit rate · writes per count row · reconciler corrections · like rate per account.

At 10×: more partitions for like rows and more counter consumers; the per-photo batching means the count table barely grows.

Common mistakes:

• Incrementing on every request, so double taps and retries inflate counts.
• One count row updated per like, locked by every liker of a viral photo.
• Only a counter, with no like rows: no likers list, no undo, no repair.
• Fetching counts one photo at a time.

13. Try it, check yourself, read more

The hot-counter lab. One photo is getting likes fast. Choose how many counter rows it's split across and how long the counter batches before writing. A single row is comfortable up to about 500 locked updates a second here.

A simple model: without batching, every like is one update spread evenly over the rows; with batching, each row gets at most one update per window. Reading the count sums all rows (cached). The 500/s row limit is illustrative; measure your database.