> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Curveball Byte News Feed
> Strategies for designing scalable social news feeds covering celebrity caching, prioritized fan-out to reduce latency, and read-time relevance ranking with trade-offs and measurement guidance
Towards the end of a system-design interview you’ll often be asked follow-up questions that require adapting your design to meet new constraints. This article walks through three common follow-ups for a social news-feed system and concise, practical ways to address them: handling a power user with many celebrity follows, reducing fan-out latency, and adding relevance-based ranking.
Before designing changes, always measure the current system: latency, queue backlog, cache hit rates, and hot-key access patterns. Optimize based on data rather than assumptions.
***
## Follow-up 1 — A power user follows many celebrities
Scenario: Alan follows 20,000 accounts, 800 of which are celebrities. Each time he opens the app the system must gather recent posts from those 800 celebrity accounts. Should you change the design?
Key observations
* The size of Alan’s follow list (20k) is not the main issue if the list itself is cached (for example, in Redis).
* The real cost comes from repeatedly querying the database for each celebrity’s recent posts on every read.
Recommended fix — Shared small caches for celebrity posts
* Maintain a small cached list (e.g., a limited list of recent post IDs) per celebrity account. This per-celebrity cache is shared among all followers.
* Instead of 800 DB queries, the feed read fetches 800 small lists from cache.
* Because there are only a few thousand celebrity accounts total, storing these small caches in Redis is feasible.
* This prevents repeated DB hits when many followers request the same celebrity posts.
Edge case — extremely popular celebrity (100M followers)
* Naive fan-out could cause a storm of reads when a celebrity posts. Caching celebrity posts prevents each follower from hitting the database repeatedly.
* For writes, avoid a single blocking fan-out: perform prioritized fan-out (see Follow-up 2) and rate-limit or batch writes to follower lists when appropriate.
Secondary issue — feed churn for extreme follow counts
* A user who follows 20k accounts will see a feed that churns rapidly as new posts push older ones out of their (capped) feed list. Typical systems cap per-user candidate lists (e.g., 500 post IDs) and only surface the top N (e.g., 50).
* Trade-offs: you can increase per-user cache size or provide persistent per-user storage if you must preserve more history, but that increases cost. Most products prioritize top-of-feed freshness for active reading.
***
## Follow-up 2 — New posts take 8 minutes to reach follower lists
Scenario: New posts are delayed — it takes 8 minutes for a post to appear in all followers’ feeds. How do you fix it?
Step 1 — Measure
* Measure latency from post creation to the point the last follower list is updated. Identify whether the queue is accumulating tickets and where the bottleneck lies (queue length, worker throughput, DB writes, network IO).
If the queue is the bottleneck
* Increase worker parallelism: add more workers to consume the queue concurrently.
* Be deliberate: adding workers raises cost and operational complexity. Scale where it provides the best latency improvement per dollar.
A better approach — prioritized (or staged) fan-out
* Don’t treat all followers equally during fan-out. Prioritize active or recently-active followers first.
* When a worker processes a post, it first pushes the post to lists of followers who are online or were recently active.
* The remaining followers receive the post in a secondary pass.
* Benefits:
* Active users see the post quickly, improving perceived freshness.
* Peak load is reduced because many inactive users won’t notice a small delay.
When combined with caching and rate-limiting strategies (e.g., batching writes to follower lists), prioritized fan-out reduces perceived latency while controlling cost and complexity.
***
## Follow-up 3 — Product wants a ranked feed (relevance over recency)
Scenario: Product wants relevance-based ranking rather than strictly newest-first ordering. What changes are required?
What does not change
* Core storage tables, the event queue, worker fan-out, and the post cache can remain as-is.
* We still maintain per-user candidate lists (e.g., newest 500 post IDs) populated by fan-out workers.
What does change — read-time scoring pipeline
* On a feed read, fetch a bounded candidate set (for example, newest 500 post IDs from the user’s list, merged with celebrity caches).
* Send these candidates to a dedicated scoring service that computes a relevance score for each candidate and returns posts sorted by score.
* Return the top N items (e.g., top 50) to the user.
Why scoring happens at read time
* Ranking depends on dynamic signals that change after publish: likes, comments, recent interactions between the viewer and the author, and time-decayed signals.
* Precomputing scores at write-time becomes stale; computing scores at read-time over a bounded candidate set keeps results relevant.
Costs, trade-offs, and mitigations
* Increased per-read CPU and IO because the scoring service must fetch dynamic metrics (likes, comments, user interactions) for each candidate.
* Post ordering can change between reads. If duplicates on refresh are problematic, maintain a per-user "seen" set or deduplication filter.
* Keep the candidate set bounded (a few hundred) to control scoring latency. Use feature caches for common metrics to reduce IO.
Comparison table — options and trade-offs
| Change | Benefit | Cost / Trade-off |
| - | - | - |
| Per-celebrity post caches | Avoid many DB reads for popular accounts | Extra memory in cache (Redis) |
| Prioritized fan-out | Faster delivery to active users, lower perceived latency | More complex worker logic and routing |
| Read-time ranking (scoring service) | Relevance improves engagement | Higher per-read CPU/IO and possible ordering variance |
| Larger per-user candidate lists | More content to score and persist | Higher storage and longer ranking latency |
When adding ranking, always score a bounded candidate set at read time (e.g., the newest few hundred candidates). This limits latency while allowing dynamic signals to influence ordering.
***
## Final notes
* The news-feed pattern (fan-out, caching, prioritized updates, and read-time ranking) is common across Twitter, Instagram, and Facebook. The right choices balance cost, latency, and user experience.
* In interviews, emphasize measurement first (queue backlogs, cache hit rates), prioritize work that improves user-visible metrics, and clearly state trade-offs for each option.
* Practice explaining how caching, prioritized fan-out, and read-time scoring work together: that combination is a robust approach for scalable, low-latency, and relevant news feeds.
Review these follow-ups so you can discuss trade-offs, metrics to measure, and concrete implementation steps confidently in an interview.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.