Designing a News Feed / Infinite Scroll System

The plain-language idea

"Design the frontend architecture for a social media news feed" (Twitter/Instagram-style, continuously scrolling) is one of the most common frontend system design prompts, and its strength as a question is that it's really three already-solved problems stacked together, plus one genuinely new one:

• The feed is paginated — it never loads all at once, and new posts get added to the underlying dataset constantly, even while a user is scrolling.
• The same post can appear in more than one view — the main feed, a user's profile, a "post detail" screen after tapping in — and a like or edit anywhere has to be reflected everywhere.
• The feed is long and rendering-heavy at scale — hundreds of scrolled-past posts sitting in the DOM is a real performance cost.
• New posts can arrive at the top while someone is already reading further down — the one piece this prompt adds that isn't just a reapplication of an existing pattern.

A strong answer names each of these explicitly and reaches for the right existing tool for the first three, spending its real thinking time on the fourth.

See it in a real thing: a Twitter/Instagram-style feed

Walking this prompt as an interview answer: the pagination shape is the classic argument for cursor-based pagination over offset-based — this track's pagination-strategy reasoning applies directly here, since a feed is exactly the case where offset breaks down. New posts are constantly inserted at the front of the underlying data, so an offset like "give me items 20–40" silently shifts under you between requests, duplicating or skipping posts. A cursor ("give me everything after post abc123") stays stable regardless of what's been added ahead of it.

Caching needs the normalized client-state shape this track's client-side state architecture lesson covers: a post that shows up in both the main feed and a user's profile is the same entity, not two independent copies. Store each post once, keyed by id, and have both views reference it — a like or edit updates one record and both views reflect it instantly, instead of drifting out of sync because only one copy got touched.

Rendering hundreds of scrolled-past posts is a natural fit for list virtualization, covered in the Web Performance track — worth naming as an ingredient here, not re-explaining; this lesson's job is recognizing where it fits, not implementing it.

What people usually miss

Watch out

• Auto-inserting new posts at the top is a common wrong first instinct, not a minor detail — it actively disrupts the exact thing a scrolling reader is doing. The "N new posts" button pattern is the answer interviewers are listening for.
• Cursor-based pagination isn't just "the modern choice" — it's specifically what a constantly-growing dataset requires. Offset pagination degrades in this exact scenario (frequent inserts), which is why this prompt is the canonical example for the choice.
• The same post shown in two places is a caching-consistency problem, not two separate features. Naming the normalized-cache reasoning explicitly is a stronger answer than describing the feed and profile view as if they're unrelated.
• Virtualization is one ingredient, mentioned by name, not the whole answer. A candidate who spends all their time on virtualization mechanics and never reaches pagination or the new-items UX has answered a performance question, not a system design one.

Why this matters in interviews

"Design a news feed" is a canonical frontend system design prompt precisely because a strong answer has to correctly assemble pagination, caching consistency, and rendering performance while also handling the live-update UX question — breadth and judgment both get tested at once.