Design a Social-media feed

01Concrete scale assumptions

02Architecture decisions and rationale

03Client contracts and data boundaries

1type FeedPage = { entries: { postId: string; rankToken: string }[]; nextCursor: string | null };2type ReactionCommand = { mutationId: string; postId: string;3  reaction: 'like' | 'none'; baseVersion: number; };

04Failure-mode analysis

05Observability and operations

• Measure first-page latency, next-page failures, duplicate rate, scroll jank, media errors, optimistic rollback, and new-post buffer depth.
• Trace page cursor hashes and request ids without logging private ranking features.
• Measure long tasks and rendered node count during long sessions.
• Experiment with ranking presentation behind cohort flags and guard user-control regressions.

06Security and accessibility boundaries

• Authorize every reaction and content visibility server-side; never rely on hidden controls.
• Sanitize user text and restrict media/URL rendering.
• Use semantic articles and headings, meaningful media alternatives, labelled actions, and non-color reaction state.
• Provide Load more and New posts controls with announcements instead of scroll-only discovery.

ANSOne full answer, start to finish

Drive the discussion yourself first. This is one strong answer delivered the way you would say it in the room — a model, not the only correct design.

A feed answer is really three sub-problems: getting pages of ranked content, keeping scrolling smooth no matter how far someone goes, and handling likes and new posts without the screen jumping around. Address them in that order and be explicit that the ranking itself is the server's job, not the client's.

1. Step 1 · Clarify

   Ask: 'Is the feed ranked by an algorithm or chronological? How often do new posts arrive at the top? Roughly how long is a typical scrolling session? And what interactions — just likes, or comments and shares too?' Assumptions: 'Algorithmically ranked, new posts arrive frequently, sessions can be very long, and interactions are like, comment, and share.' Long sessions push you toward virtualization; frequent new posts push you toward a 'new posts' banner instead of auto-insert.

2. Step 2 · Requirements

   User-facing: an endless feed that loads more as you scroll, instant feedback when you like something, and a non-disruptive way to see new posts. Hidden: the client must not re-rank or dedupe incorrectly, the DOM must stay bounded however far you scroll, and a like shown in one place must update everywhere that post appears.

3. Step 3 · Paging with a cursor

   'The initial load fetches the first page of ranked posts plus a cursor. Scrolling near the end fetches the next page using that cursor. I use a cursor, not a page number, because the ranked list shifts as new content is inserted — an offset page would show duplicates or gaps. Pages are merged into the store by post id so a post returned on two pages is not rendered twice.'

4. Step 4 · A normalized store keyed by post id

   'Posts are stored once, by id. A component rendering the feed, and a notification that says someone liked your post, both point at the same record. So when a like count changes in one place it is correct everywhere, because there is only one copy of the truth.'

5. Step 5 · Virtualized rendering

   'Only the posts near the viewport are actually in the DOM; as you scroll, rows enter and leave. This keeps the node count flat whether you have scrolled past 20 posts or 2,000. It has to preserve stable keys, keep focus working, and anchor the scroll position so nothing jumps.'

6. Step 6 · Optimistic likes and the 'new posts' banner

   'A like updates the local count and the liked state immediately, sends the request, and reconciles — or rolls back with a message — on the response. For new content, a lightweight poll or push checks whether there are posts newer than the current top, and if so shows a New posts button. I do not silently prepend them, because that shoves the content you are reading down the screen.'

7. Step 7 · What loads first, and what to measure

   'Per post: text and the primary media's dimensions or a preview first, so nothing shifts; comments, adjacent media, and analytics follow. After launch I would watch page-fetch latency, duplicate rate, rollback rate on optimistic actions, layout shift from media, and interaction delay, alongside the engagement numbers.'

QAInterview questions and model answers