> ## 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.
# News Feed Requirements and Estimation
> Designing a scalable social news feed for interview problems, detailing functional and non functional requirements, traffic estimation, read heavy trade offs, caching and fan out strategies.
Let's design a news feed for an interview question. Be precise about what "news feed" means: in interviews it's the main, scrollable list of posts or items you see on the first screen of a social app—not the whole app. Examples:
* On LinkedIn the first screen shows posts from people you follow — that is its news feed.
* On X (formerly Twitter) the first screen shows tweets from accounts you follow — that is its news feed.
A feed is a sorted list of posts that users can endlessly scroll. Our job is to design a system that efficiently builds and serves that list under realistic constraints.
We’ll follow a six-step framework, beginning with clarifying requirements. At this stage, gather the minimum set of functional and non-functional requirements needed to scope the design.
Step 1 — Clarify requirements
1. What goes into the feed and how is it ordered?
* If the interviewer limits the feed to posts from accounts a user follows and asks for newest-first ordering, the problem reduces to timestamp-based sorting. If instead a ranking algorithm is required, that becomes a larger ranking problem that needs signals (post age, creator relationship, likes/reactions, engagement, etc.) and an online or offline scoring pipeline.
2. How quickly must a new post appear in followers' feeds?
* Example: "A few seconds is fine; it shouldn't take minutes."
3. What is the target feed load latency?
* Example: "The feed should load within 1 second on open."
4. Which content types should the feed support?
* Example: "Text, images, and videos."
5. Is occasional duplication after refresh acceptable?
* Example: "Yes — occasional duplicates after a refresh are acceptable."
Scope for this example (explicitly state what we will design):
* Users can follow other accounts.
* Users create posts that include text, images, or videos.
* The feed shows the newest posts only from accounts a user follows.
* Feed must load within 1 second on open.
* A new post should reach followers within a few seconds.
* Occasional duplicate posts on refresh are acceptable.
Use this table to summarize functional and non-functional requirements:
| Requirement type | Requirement | Example / Notes |
| - | - | - |
| Functional | Source of feed items | Only posts from accounts a user follows |
| Functional | Ordering | Newest first (timestamp-based) |
| Functional | Content types | `text`, images, videos |
| Non-functional | Feed load latency | Load feed ≤ 1 second |
| Non-functional | Propagation latency | New post visible to followers within a few seconds |
| Non-functional | Consistency | Eventual consistency acceptable; occasional duplicates fine |
Step 2 — Back-of-the-envelope estimation
Ask about scale: how many users, how often do they open the feed, how frequently do they post? Example assumptions below produce a realistic read-heavy workload and will guide architecture choices (caching, pre-computation, and fan-out).
Assumptions
* Daily active users (DAU): 10,000,000
* Average opens per user per day: 5
* Average posts per user per month: 3
Calculations
* Feed reads/day = 10,000,000 × 5 = 50,000,000 reads/day
* Seconds per day = 86,400 → reads/sec ≈ 50,000,000 / 86,400 ≈ 580 reads/sec
* Total posts/month = 10,000,000 × 3 = 30,000,000 posts/month
* Posts/day ≈ 30,000,000 / 30 ≈ 1,000,000 posts/day
* Writes/sec ≈ 1,000,000 / 86,400 ≈ 12 writes/sec
* Read : write ratio ≈ 580 : 12 ≈ 48 : 1 (≈ 50 reads per write)
Summarized in a table:
| Metric | Value |
| - | - |
| DAU | 10,000,000 |
| Opens per user / day | 5 |
| Reads/day | 50,000,000 |
| Reads/sec (avg) | ≈ 580 |
| Posts/month | 30,000,000 |
| Posts/day | 1,000,000 |
| Writes/sec (avg) | ≈ 12 |
| Read : write ratio | ≈ 48 : 1 |
These numbers show the system is read‑heavy. That should drive design decisions: favor low-latency read paths, caching, and pre-computation (fan-out strategies) over write-optimized designs.
The key takeaway from estimation: the feed is read-heavy. Prioritize fast read paths (caching and pre-computation/fan-out) and acceptable eventual consistency. Use the read/write ratio to justify design trade-offs during your interview.
Next steps in the six-step framework (not covered here) would include choosing a high-level architecture (push vs. pull fan-out), designing data models for posts and user relationships, defining storage and caching layers, and outlining operational concerns (monitoring, throttling, and backpressure). For reference and deeper study, consider these resources:
Links and References
* [Kubernetes Documentation](https://kubernetes.io/docs/) — for running scalable services
* [System design primer on GitHub](https://github.com/donnemartin/system-design-primer) — good interview prep and patterns
* [Designing data-intensive applications (book)](https://www.oreilly.com/library/view/designing-data-intensive-applications/9781491903063/) — background on storage and replication patterns
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.