System Design

Like Counter

Design the like counting system for a social app like Instagram or YouTube.

Functional requirements

• A signed-in user can like or unlike a post; the action is a toggle, so liking an already-liked post is a no-op rather than a second like.
• Every post shows a like count to anyone viewing it (e.g., '1.2M likes' on a viral reel, '37 likes' on a friend's photo).
• When a user opens a post, the response says whether that user has already liked it, so the heart renders filled or empty correctly.
• Clients can fetch the counts and the viewer's own like state for a batch of posts in one call (e.g., the 20 posts on a feed page).
• Support several reaction types on one post (e.g., like, love, and laugh as on Facebook) with a count per type; a user holds at most one reaction per post, and switching moves it between types.

Non-functional requirements

• Reads are the critical path: p99 under 50ms for a batch read of 20 posts; a like or unlike is acknowledged to the tapping user within 200ms at p99.
• Consistency is split: the displayed count may be approximate, rounded (e.g., '1.2M'), and up to 10 seconds stale, but the viewer's own like state must be exact and read-your-writes, so their heart never flips back after tapping.
• A like is never counted twice for one user, under double taps, client retries, or duplicate delivery; a like followed by an unlike leaves the count unchanged.
• Durability: an acknowledged like is never lost, and the count can always be rebuilt from the per-user like records, so drift in a displayed count is correctable.
• Abuse: enforce one reaction per account per post and a per-account like rate limit (e.g., 60 per minute); detecting fake accounts is out of scope.

Scaling & constraints

• 1B monthly active users; ~20,000 likes per second on average (~1.7B per day), peaking at 200,000 per second during major events.
• A single viral post (a celebrity announcement or a live sports moment) can draw 30,000 likes per second on its own for 10-20 minutes and accumulate 50M likes.
• Read:write ratio is roughly 1,000:1: every feed impression reads counts for ~20 posts, about 50M count reads per second at peak.
• Each like record (user_id, post_id, reaction type, timestamp) is ~40 bytes; ~600B new records per year, ~25TB before replication, retained indefinitely.
• Skew: 90% of posts never pass 100 likes, while the top 0.01% of posts draw about half of all likes and reads.
• Duplicates are routine: about 2% of like requests arrive twice because of client retries on flaky mobile networks, and repeated taps within a second happen on ~1% of likes.

Out of scope

• Who-liked lists and 'liked by your friends' social proof.
• Fake account and bot detection beyond per-account rate limits.
• Notifying the post author about new likes.
• Ranking and feed effects of like counts.