. Design a News Feed (Infinite Scroll & Real-time) – Frontend System Design Interview Guide

I'll start by defining what makes a great feed experience—what questions does a user need answered as they scroll? Then I'll design the data pipeline that handles infinite scrolling, real-time updates, and optimistic interactions. Finally, I'll design the component architecture with clear separation between server state and UI state.

Why this approach?

Most candidates build a "list of posts." Strong candidates build a "feed experience"—a system that feels instant, preserves scroll position, and handles real-time updates gracefully. The difference is thinking about the entire user journey, not just rendering a list.

Think of this like building a social media feed. You don't just show posts—you handle infinite scrolling, real-time updates, optimistic interactions, and media loading. Same principles apply here.

What we're doing: Designing the React component structure, data flow, and how components communicate. This is where we decide the component hierarchy, props flow, and React-specific patterns.

React Component Architecture

What we're building: A React application with clear component hierarchy, efficient data flow, and separation of concerns between UI, state, and data fetching.

Component Hierarchy

Top-Level: FeedContainer

• Root component managing feed state and pagination
• Handles infinite scroll logic and prefetching
• Coordinates real-time updates from WebSocket
• Manages virtual scrolling for performance

Component Tree:

FeedContainer (smart component)
├── FeedHeader
│   ├── PullToRefresh
│   └── NewPostsBanner
├── VirtualizedFeedList
│   └── PostCard[] (presentational)
│       ├── PostHeader
│       │   ├── Avatar
│       │   ├── Username
│       │   └── Timestamp
│       ├── MediaViewer
│       │   ├── ImageCarousel
│       │   └── VideoPlayer
│       ├── PostContent
│       │   ├── Caption (with Mentions/Hashtags)
│       │   └── LocationTag
│       ├── InteractionBar
│       │   ├── LikeButton
│       │   ├── CommentButton
│       │   └── ShareButton
│       └── CommentSection
│           ├── CommentList
│           └── CommentInput
└── LoadingState
    └── SkeletonCard[]

Data Flow in React

Top-Down Data Flow (Props):

FeedContainer (fetches posts via React Query)
  ↓ props: posts[]
PostCard (receives post data)
  ↓ props: post, onLike, onComment
InteractionBar (receives handlers)

Bottom-Up Events (Callbacks):

LikeButton (onClick)
  ↓ callback
PostCard (handleLike)
  ↓ callback
FeedContainer (updatePostState)
  ↓ mutation
React Query (optimistic update + API call)

Real-time Updates (WebSocket → React Query):

WebSocket (receives update)
  ↓ event handler
FeedContainer (processUpdate)
  ↓ update cache
React Query (setQueryData)
  ↓ automatic re-render
PostCard (receives updated props)

Tradeoffs & Comparisons

• CSR vs SSR/ISR: Rendering Strategies

Entity and interface contract shape with cache/reconciliation model for a frontend system design interview (backend treated as a black box).

Entity and interface contract shape for a frontend system design interview (backend treated as a black box).

1) Component prop interfaces (boundaries)

Define clean boundaries across feed container, post card, and interaction controls.

• FeedContainerProps: feed context and list-level callbacks
• PostCardProps: post summary + interaction handlers
• FeedHeaderProps: refresh and new-post banner controls
• CommentDrawerProps: thread UI state and submit callbacks

2) Hook interfaces (consumption contracts)

Use hook return contracts to keep integration discussion concrete but lightweight.

Data model (Entities)

A feed is mostly server-originated data (posts/authors/comments). Client data is mostly UI state + optimistic/offline queues.

Client cache shape (recommended)

Even if we use React Query, conceptually the cache is:

• postsById: Record<PostId, Post>
• usersById: Record<UserId, Author>
• feedIds: PostId[]
• pageInfo: { nextCursor, hasMore }

This enables:

• Deduping across pages
• O(1) realtime patches by postId
• Stable rendering order while data updates

Deep dive: Data Normalization

Consistency & reconciliation rules

• Writes are idempotent via idempotencyKey.
• Realtime events include eventId and/or updatedAt.
• Ignore stale realtime events older than cached updatedAt.

Tradeoffs & Comparisons

• Normalized vs Denormalized: Data Normalization

React interfaces & integration patterns (props, hooks, callbacks).

This section covers API contracts and React consumption patterns.

API contracts (Backend as black box)

Feed

GET /api/feed?cursor=<opaque|null>&limit=10
=> {
  items: PostSummary[],
  pageInfo: { nextCursor: string | null, hasMore: boolean }
}

Contract rules:

• Cursor is opaque (client never parses it)
• Ordering is stable (rank key + deterministic tie-break)
• Client dedupes by postId across pages

Post detail (optional hydration)

GET /api/posts/:id
=> { post: Post }

Like (idempotent)

POST /api/posts/:id/like
body: { like: boolean, idempotencyKey: string }
=> { likedByMe: boolean, likeCount: number, updatedAt: string }

Comments (paged)

GET /api/posts/:id/comments?cursor=<opaque|null>&limit=20
POST /api/posts/:id/comments
body: { content: string, idempotencyKey: string }
=> { comment: Comment, commentCount: number }

Real-time events (schema)

// WS/SSE payloads (examples)
{ type: 'POST_LIKES', eventId: string, postId: string, likeCount: number, updatedAt: string }
{ type: 'POST_COMMENTS', eventId: string, postId: string, commentCount: number, updatedAt: string }
{ type: 'NEW_POST_AVAILABLE', eventId: string, postId: string, createdAt: string }

Type definitions used in contracts

interface PostSummary {
  id: string;
  authorId: string;
  caption: string;
  likeCount: number;
  commentCount: number;
  likedByMe: boolean;
  createdAt: string;
  updatedAt: string;
}

interface Post extends PostSummary {
  media: Array<{ id: string; type: 'image' | 'video'; url: string }>;
}

interface Comment {
  id: string;
  postId: string;
  authorId: string;
  content: string;
  createdAt: string;
}

3) Integration patterns (React wiring)

• Data down, events up: hooks own server-state; UI emits user intent.
• Optimistic interactions: apply local like/comment patch, rollback on failure.
• Realtime patching: update counters by postId; defer inserts behind banner.
• Scroll preservation: keep viewport stable during refresh and live updates.

What we're doing: Optimize rendering, media loading, request behavior, and interaction responsiveness for scale.

Optimistic UI Updates

Use one predictable optimistic flow: update UI immediately, rollback on failure, then revalidate.

onMutate: snapshot -> optimistic patch
onError: rollback(snapshot)
onSettled: invalidate(['feed'])

Mentions/Hashtags and Timestamp Parsing

Pattern-matching and formatting snippets are intentionally moved to the optional LLD section at the end.

Offline Support

• Cache viewed content
• Queue failed write actions
• Retry queue on reconnect
• Show explicit offline/online state

Memory and Scale Guardrails

• DOM budget via virtualization
• Bound cache size by page count
• Dispose observers/listeners aggressively
• Track Web Vitals and API latency/error budgets