React System Design interview questions

TL;DR: React system design interviews evaluate whether you can architect large, reliable, and performant frontends—not just build components. Expect questions about separating global UI state from server state, structuring design systems with tokens and theming, adopting React Server Components thoughtfully, enforcing accessibility, and building real-time experiences like infinite scroll feeds or chat systems. Strong candidates demonstrate clean data-flow modeling, cache-aware design, performance optimization, and the ability to reason about reliability, scalability, and user experience under real-world constraints.

Modern frontend roles increasingly include React system design interviews, where companies expect you to reason about architecture, data flow, component boundaries, performance, accessibility, and real-time experiences. This blog explores essential React system design interview questions and demonstrates how to answer them with clarity and depth.

Separating global state from server state in React#

A recurring topic in React architecture interviews is distinguishing global UI state from server state. Mixing them often leads to unmaintainable, tightly coupled systems.

Server state#

In interviews, expand on how server state interacts with caching lifecycles. Mention strategies like background revalidation, stale-while-revalidate, partial hydration for list views, and optimistic updates when mutations occur. Discuss cache keys, invalidation patterns, and how to prevent over-fetching in highly interactive UIs.

Server state:

• Originates from backend APIs

• Is asynchronous, cacheable, and can become stale

• Should be treated as the source of truth

Use React Query or SWR to manage server state because they:

• Cache responses in memory

• Handle automatic revalidation

• Prevent refetch waterfalls

• Support pagination, infinite queries, and background sync

Server state does not belong in Redux, Zustand, or Context.

Global client state#

Clarify how global UI state should remain lightweight and predictable. Describe using slices or atoms for modularity, separating ephemeral UI logic from persistent user settings, and employing statecharts for complex flows. Mention avoiding prop drilling through composition patterns and colocating state thoughtfully.

Global UI state encompasses:

• Theme preferences

• Modal visibility

• Local filters

• Wizard progress

• Form inputs not yet submitted

Store this in a global client store (Zustand, Redux Toolkit, Jotai, Recoil) or React Context.

Building a scalable design system with tokens and theming#

A common interview question asks how to structure a design system that is robust, themeable, and maintainable.

1. Start with design tokens#

Elaborate on how tokens enable cross-platform design consistency. Mention compiling tokens to multiple outputs (CSS, JS, native), naming conventions, dark mode variants, and how tokens support brand theming at scale.

Define design tokens as your canonical source of truth for:

• Colors

• Typography

• Spacing

• Radii

• Shadows

• Breakpoints

Tokens can be JSON files, CSS variables, or TypeScript objects.

2. Build primitive components#

Add detail on composition patterns, accessibility hooks, and ensuring primitives expose flexible APIs without leaking styling decisions. Discuss testing primitives thoroughly to avoid regressions across the system.

Develop foundational components such as:

• Button

• Input

• Text

• Card

• Modal

These should support variants, sizes, states, and theme overrides.

3. Add theming support#

Implement theming with:

• CSS variables

• ThemeProvider in Emotion/Styled Components

• Tailwind with CSS variable tokens

• Vanilla-extract

Themes should override only the design tokens, not component logic.

4. Document in Storybook#

Show component usage, accessibility notes, and code examples. This ensures consistency across teams.

When to adopt React Server Components (RSC)#

React Server Components can improve performance significantly, but they must be adopted thoughtfully.

Use RSC when:#

Explain how RSC reduces hydration costs, enables streaming partial UI, and minimizes client-side JS. Mention bundler impacts, cache strategies on the server, and how to coordinate server and client boundaries for maintainable architectures.

• You want to shift data-fetching to the server

• You want to reduce bundle size

• The UI section has low interactivity

• You want to avoid client-side waterfalls

Avoid RSC when:#

• The component uses browser APIs

• The UX requires heavy interactivity

• Advanced event handling is required

Adopt RSC incrementally—start with data-heavy, low-interactivity areas.

Accessibility checklist for React components#

Accessibility is a must-have for production UI systems.

Checklist#

Add deeper audits: color contrast analysis, reduced-motion support, high-contrast modes, pointer target sizing, and aria-expanded/aria-controls usage. Mention running automated checks (axe), manual screen reader navigation, and usability testing patterns.

• Use semantic HTML

• Apply ARIA attributes only when necessary

• Support full keyboard navigation

• Avoid focus traps and ensure logical focus order

• Include visible focus styles

• Label all controls explicitly

• Use aria-live regions for async updates

• Test with screen readers (VoiceOver, NVDA)

Designing an infinite-scroll feed with caching and prefetching#

Infinite scroll is a common system design question that tests both data and UI architecture.

Best practices#

Also consider error recovery when pages fail, visual placeholders for loading states, preventing layout shifts, caching metadata for quick renders, and tuning virtualization window sizes. Mention preloading media and using AbortController to cancel outdated fetches.

• Use cursor-based pagination

• Cache pages by cursor

• De-duplicate feed items by ID

• Prefetch next pages when the user nears the bottom

• Pause network fetching when the tab is hidden

• Use React Query Infinite Query or SWR Infinite

• Use Intersection Observer for scroll detection

• Virtualize large lists for performance (React Window)

Designing a chat or notification panel with presence indicators#

Real-time communication features are a classic React system design interview topic because they test your knowledge of event-driven architecture, state modeling, concurrency, and rendering performance under load. A great answer demonstrates not only how to build chat or notifications, but how to keep them responsive and scalable as the user base grows.

Architecture#

A production-grade chat or notification system must gracefully handle unreliable networks, multi-device sessions, partial failures, and large bursts of activity.

Enhance your architecture discussion with:

• Reconnection strategies: Use exponential backoff, jitter, and session resume tokens when the connection drops.

• Distributed fanout: For large channels or rooms, rely on backend fanout services (Pub/Sub, WebSocket gateways) rather than the client connecting directly to every event stream.

• Message ordering guarantees: Explain how you maintain ordering via sequence numbers, server timestamps, or vector clocks.

• Fallback channels: When WebSockets fail, fall back to SSE or periodic polling; this shows reliability-focused thinking.

• Multi-device sync: Keep unread counts, presence, and message state consistent across tabs and devices.

Use WebSockets or SSE to stream events such as:

• New messages

• Presence updates

• Typing indicators

• Room membership changes

• Notification pushes

State management#

A strong state strategy prevents bugs like double messages, duplicated notifications, or flickering presence indicators.

Expand your answer by highlighting:

• Normalized message stores to avoid duplication and enable quick updates.

• Separate slices for rooms, users, presence maps, and unread counts.

• Event sourcing patterns where incoming events update the store via reducers or state machines.

• Replayable events for debugging or restoring UI after reloads.

• Optimistic message delivery while waiting for server acknowledgment.

State tools that work well:

• Zustand

• Redux Toolkit

• Jotai

• Recoil

Performance considerations#

High-volume message streams can crush React apps if not managed properly. Expand your answer with additional considerations:

• Render batching and debounce: Combine multiple incoming events into a single render cycle.

• Windowed or virtualized lists: Essential when rooms contain thousands of messages.

• Selective re-rendering: Use selector-based stores (Zustand, Redux) to update only the components that need it.

• Off-main-thread processing: Move expensive formatting or sorting into Web Workers.

• Incremental hydration: In hybrid RSC apps, hydrate only interactive parts of the chat.

• Caching heuristics: Cache avatars, user profiles, and media previews to prevent repeated fetches.

• Presence heartbeats: Send small pings to maintain online/offline indicators but throttle them to avoid noise.

• Visibility API optimizations: Pause incoming message rendering when the tab is hidden.

Additional system-level features interviewers expect#

• Unread count strategy: Distinguish between per-room unread counters and global notifications; persist them between sessions.

• Message retries: Build retry queues with dedupe IDs to ensure at-least-once delivery without duplication.

• Attachment uploads: Handle multipart uploads, progress indicators, and resumable uploads.

• Security and permissions: Enforce who can send messages, edit them, or view presence.

• End-to-end encryption considerations: For advanced roles, discuss how encryption affects indexing, search, and caching.

Final thoughts#

Modern React roles require system-level thinking. With a strong grasp of how to separate global and server state, build design systems, apply accessibility principles, reason about RSC adoption, and architect robust real-time features like chat and notifications, you'll be prepared for the key React system design interview questions.

Happy learning!