Hot posts, likes, ranking and what breaks

Part of the free System Design course on LogicWiz, in the chapter: Design a news feed. The interactive whiteboard exercises and simulations run in the app.

Week 14, Day 3: The post everyone asked for at once

"The cricketer posted at 8:02. The like counter froze at 8:03. By 8:09, half his followers still had not seen the post."

Meera, in the incident review

Deep dive 1: a hot post and the cache

When a star posts, millions of feed reads ask for the same post within seconds. Even with the hybrid, this is a hot key: one key that gets far more traffic than any other.

Weak: load the star's recent posts from the post store on every feed read. If a quarter of the 17,000 reads per second include this star, that is about 4,000 reads per second on one partition. It struggles, and unrelated authors on the same partition suffer with it.

Good: cache the star's last 20 posts and their bodies, with a short TTL (time to live: the cache deletes the entry after that time). If 99 of 100 reads hit the cache, the store sees 1% of 4,000, about 40 reads per second. Add request coalescing: when many requests miss the same key together, one goes to the store and the rest wait for its answer.

Great: also copy the hot key into more places. Each feed server keeps the star's latest posts in its own memory for a couple of seconds, so the shared cache sees one request per server per few seconds, not thousands. Copy the key across several cache shards too, so one node does not serve a whole country.

The trade-off is that a hot post can be a few seconds old, and you spend a little memory. In return the store survives the biggest spikes. Edits and deletes need an explicit invalidation event that removes the old copy. Waiting for the TTL is not enough for a deleted post.

Deep dive 2: counts, and why an exact like count is expensive

The star's post gets 2 million likes in 10 minutes. That is about 3,300 likes per second on one post.

Meera's first design had a column, likes, and each like did "add 1". It looks cheap. But every like touches the same row, and the database must apply those updates one at a time, to keep the count right. Updates queue up behind one lock. How many a single row can take depends on the database, but the limit is one machine, and adding machines does not raise it. You also need a rule that one person can like once, which means checking before adding.

Weak: one counter row, updated on every like.

Good: a likes table keyed by (post_id, user_id). The unique key stops double likes and answers "did I like this?". Partition the table by the pair, not by post alone, or one star's likes all land on one partition. The displayed count comes from a counter in the cache, increased by each like. The counter can always be rebuilt from the table.

Great: split the counter into 16 sub-counters. Each like adds to a random one, and the total is their sum. Now 3,300 likes per second spread to about 210 per sub-counter. Or aggregate in memory and flush a batch every second. Show an approximate count ("2.1M"), and let a background job recount from the likes table.

Why exact counts are expensive: an exact, instantly correct number needs all writers to agree on one order, so they wait for each other at a single place. An approximate number lets writers work in parallel. The trade-off is a count that lags by seconds and may be slightly off, while the likes table stays the truth.

Deep dive 3: ranking, after chronological works

Interviewers say: "Now rank the feed instead of newest first." The strong answer keeps the storage unchanged. The feed store becomes the candidate list. The feed service takes the top 200 candidate ids, merged with big-account posts, and scores each one with a model. Typical signals are age, how often you interact with that author, and how much attention the post gets. It returns the best 20.

Do the cost: 17,000 reads x 200 candidates is 3.4 million scores per second. The scorer must be a small, fast model, or use features computed ahead of time, all within the 200 ms budget. Paging changes too. The first request ranks the candidates and keeps the ordered ids for a few minutes under a token. The cursor points into that list, so pages do not reshuffle.

What breaks, and how you notice

• Fan-out lag grows after a burst of posts or a creator just under the threshold. Alert on consumer lag, how far the workers are behind the newest event. Feeds load, only with older posts.
• A feed cache shard dies. Those users fall back to pull, with a cap on concurrent rebuilds so the post store is not flooded. Watch cache hit ratio and feed p99.
• The post store is slow. Hydration returns the posts that arrived in time and skips the rest. A partial page beats an error.
• A post is deleted. An invalidation event clears caches, and hydration drops deleted ids anyway.

The feed cache is never the source of truth. It can always be rebuilt from the follow graph and the post store.

What Mid and Senior answers sound like, and the follow-ups

A Mid answer reaches push with a cache of ids, uses cursor paging, and puts images behind a CDN. It sees the celebrity problem when asked. A Senior answer compares push and pull with numbers, proposes the hybrid with a stated threshold, handles hot keys, inactive users and cache loss, and uses consumer lag as the key metric.

Likely follow-ups:

• An account jumps from 90K to 2 million followers overnight. Check the follower count on every post. Once past the threshold, new posts are pulled. Copies already pushed stay valid.
• Unfollow. Filter at read time against the follow list, so old posts disappear without rewriting feeds.
• "New posts available" banner. The app asks a tiny endpoint for a count since its cursor, or listens on a push channel, instead of reloading the feed.

📌 Summary: Cache hot posts with short TTLs and coalesced misses. Split a like counter into shards and show an approximate count. Rank the top 200 candidates without changing storage. Alert on fan-out lag.

What Meera learns next

A feed post can carry a video. The feed stores only a link and a thumbnail, but playing a two-hour film means gigabytes sent in small pieces over weak phone networks. Next: design video streaming.

Check your understanding

1. A quarter of 17,000 feed reads per second include the same star's latest post, and the post store partition is overloaded. What is the best first fix?
2. One post receives 3,300 likes per second, and the team runs "likes = likes + 1" on a single row. What is the problem, and what is the better design?
3. An interviewer adds ranking to a working chronological feed. Which answer fits best?
4. Which signal first tells you that new posts are reaching followers later than the 5-second target?
5. A creator with 90K followers jumps to 2 million overnight. The threshold is 100K. What happens to their new posts?