Frontend System Design Interview: A Framework and Example

A frontend system design interview asks you to design the client side of a product: a news feed, an autocomplete, a chat app, a photo gallery, a collaborative editor. Instead of databases and load balancers, you're judged on component architecture, data and state, the API contract you need, rendering and network performance, offline and error behaviour, and accessibility. A simple, repeatable structure keeps a 45-minute round on track.

A framework for the round

Worked example: a news feed

Requirements

Users scroll an infinite feed of posts with text, images and video; they can like and comment; new posts appear without a full reload; it must work on slow mobile networks and be usable with a screen reader. Out of scope: composing posts, ads.

Architecture

Data model and API

• Normalise posts and users by ID in a client cache, and store the feed as an ordered list of post IDs plus a cursor, so a like updates one place and every view of that post re-renders. See state management.
• GET /feed?cursor=…&limit=20 returns posts, embedded authors and the next cursor. See pagination.
• A server-sent events or WebSocket channel announces new posts; the client shows a "new posts" pill rather than shifting content under the user's finger. See real-time communication.
• POST /posts/{id}/like with an idempotency key, applied optimistically.

Optimisations to discuss

• Virtualize the list so only visible posts are in the DOM; prefetch the next page before the user reaches the end.
• Responsive, lazy-loaded images with fixed aspect ratios to avoid layout shift; play videos only when visible.
• Server-render or statically render the shell for a fast first paint, then hydrate. See rendering strategies.
• Optimistic likes with rollback on failure; a retry queue when offline.
• Skeleton states, error states with retry, and an empty state.
• Accessibility: semantic article elements, keyboard navigation, focus management when new content loads, alt text.

What interviewers look for

• Clear separation of server state, client state and UI.
• Network awareness: pagination, caching, deduplicated requests, cancellation of stale requests, behaviour on slow or flaky networks.
• Performance with measurement: naming Core Web Vitals and how each choice affects them.
• Robustness: loading, error, empty and offline states, not just the happy path.
• Accessibility and internationalisation as requirements, not afterthoughts.
• Trade-offs stated out loud, for example SSR's faster first paint vs its server cost.

Interviewers often probe one area deeply. Have a ready deep dive for infinite scroll, image loading, offline sync and real-time updates, since they come up again and again.