React Server Components Interview Questions: Boundaries, Streaming, Caching, and Trade-Offs

A candidate says, "Server Components are just SSR with async components." That answer sounds plausible, but it misses the two ideas interviewers usually care about: the client bundle boundary and the data protocol that lets React reconcile server-rendered UI with interactive client state.

This guide covers React Server Components interview questions at the level expected from a Senior Frontend Engineer. You will practice boundaries, composition, streaming, caching, security, and the trade-offs behind a production architecture, not just memorize what 'use client' does.

Use each question as a two-minute spoken prompt before reading the answer. Then apply the reasoning to real Frontend Engineer interview questions on PracHub. The strongest signal is not choosing "server" everywhere; it is drawing a boundary that makes performance, security, and ownership easier to reason about.

Quick Answer: What Do RSC Interviews Test?

Senior interviews test whether you can separate React's guarantees from a framework's implementation. Expect a system-design conversation involving the module graph, serialized props, Suspense boundaries, cache scope, invalidation, authorization, and client-side interactivity.

Server and Client Boundary Questions

1. What is a React Server Component?

A Server Component is evaluated in a server environment before bundling and sends its rendered result, not its component implementation, to the client. It can use server-side resources and async I/O, and its code does not become client JavaScript.

It is not automatically "per request." A framework may run it at build time, on demand, or from a cache. A good answer separates the component model from the framework's rendering policy.

2. How are RSC and SSR different?

SSR answers when HTML is produced; RSC answers where component code belongs. Traditional SSR runs components on the server to create initial HTML, then ships their JavaScript so the browser can hydrate them. A Server Component is not hydrated and its implementation stays off the client.

They often work together. On an initial framework render, React may produce an RSC payload for reconciliation and HTML for a fast first view. Client Components can still be server-rendered to HTML and later hydrated.

3. What exactly does 'use client' mark?

It marks a module boundary. That module and its transitive imports enter the client module graph, so placing the directive high in the tree can pull utilities and components into the browser bundle unnecessarily.

A common trap is saying 'use server' marks a Server Component. It does not. React has no Server Component directive; 'use server' marks an async Server Function that client code can invoke over a network boundary.

4. Can Server and Client Components render each other?

A Server Component can import and render a Client Component. A Client Component cannot directly import a module that must remain a Server Component, because that would ask the browser's module graph to execute server-only code.

Composition still works: a Server Component can render server-owned content and pass that element through children or another prop to a Client Component. The client component owns the interactive shell while the server retains ownership of the passed subtree.

5. What can cross the boundary?

Props crossing from server to client must use React-supported serializable values. Plain data, selected built-ins, promises, JSX elements, and Server Functions are supported; arbitrary functions, class instances, and non-global symbols are not.

Serializability is only half the question. Ask whether the client needs the value at all. Passing an entire database record can expose fields and enlarge the payload even when serialization succeeds.

Streaming and Suspense Questions

6. How does streaming work with Server Components?

An async Server Component can suspend while awaiting data. The nearest Suspense boundary defines a fallback that can be sent first, while later chunks fill in the completed content. Frameworks coordinate the RSC payload, HTML streaming, navigation, and hydration of Client Components.

Streaming improves progressive delivery; it does not make a slow dependency faster. A header that takes 100 ms can appear before recommendations that take two seconds, but the recommendations still take two seconds.

7. How do you prevent server-side data waterfalls?

Start independent work before awaiting it, and let separate subtrees suspend independently. Do not hide sequential dependencies behind several async components and assume React will parallelize them.

async function ProductPage({ id }: { id: string }) {
  const productPromise = getProduct(id);
  const recommendationsPromise = getRecommendations(id);
  const product = await productPromise;

  return (
    <>
      <ProductDetails product={product} />
      <AddToCart productId={product.id} />
      <Suspense fallback={<RecommendationsSkeleton />}>
        <Recommendations promise={recommendationsPromise} />
      </Suspense>
    </>
  );
}

The useful interview discussion is whether recommendations are independent, whether the fallback has stable dimensions, and whether starting that request for every visitor is worth the server work.

8. Where should Suspense boundaries go?

Place them around meaningful reveal units, not every async function. One boundary around the whole page delays useful content; dozens of tiny boundaries can create visual churn, excessive fallbacks, and complicated error behavior.

Choose boundaries using UX priority, layout stability, dependency latency, and failure isolation. Streaming and hydration are also different: Server Components do not hydrate, while the Client Components embedded in the result still need their JavaScript and hydration work.

Caching and Freshness Questions

9. What does React.cache actually cache?

cache(fn) memoizes calls made through the same cached function during a Server Component render. It is useful for deduplicating work and sharing one data snapshot across components. React invalidates that memoization across server requests.

It is not a universal CDN or database cache. Each call to cache creates a separate memoized function, object arguments depend on reference identity, and thrown errors can also be memoized for that request.

10. Is data fetched in an RSC cached by default?

There is no framework-independent answer. React defines the component and memoization primitives; frameworks decide route, data, payload, and deployment caching. A senior candidate states the framework and version before describing defaults.

For example, current Next.js documentation says fetch is not cached by default, while Cache Components can opt functions or components into caching with 'use cache'. Older Next.js versions used different defaults, so repeating a historical rule can produce a wrong production design.

11. How would you design cache invalidation?

Begin with four questions: What is the key? Who may share the value? How stale may it be? What event invalidates it? Public catalog copy may tolerate shared, time-based caching; inventory may need short freshness; a user's cart should never leak through a public cache.

Also distinguish request memoization, persistent data caches, route or RSC payload caches, browser navigation caches, and CDN caches. "We cache the page" is not a complete answer.

A Senior System Design Scenario

Prompt: Design a product page with product details, inventory, personalized pricing, recommendations, reviews, and an interactive cart.

A strong candidate first maps data ownership and freshness. Static product copy can be server-rendered and cached. Inventory and personalized price need request-aware authorization and a deliberate freshness policy. Reviews and recommendations can stream behind stable Suspense fallbacks. Quantity controls, optimistic cart state, and browser events belong in focused Client Components.

Then discuss failure behavior. Product-not-found may fail the route, while recommendations should degrade locally. Measure server render duration, time to shell, streamed completion, cache hit rate, RSC payload size, client JavaScript, hydration time, and downstream latency. This turns a component diagram into an operable system.

Practice the same decomposition with PracHub's frontend software-engineering questions, then use the frontend system design guide to rehearse requirements, data flow, rendering, and trade-offs.

Security and Production Trade-Offs

12. When would you avoid or limit RSC?

RSC is attractive when a product has meaningful server data access, large non-interactive UI, or expensive client bundles. The benefit is smaller client JavaScript and server-side composition close to the data.

The costs include more server work, network latency on navigation, framework and deployment coupling, harder boundary debugging, cache invalidation risk, and a newer security surface. A mostly client-side tool with offline behavior and intense local interaction may gain little from moving its core UI to the server.

Server execution is not a trust guarantee. Route parameters, cookies, form inputs, and Server Function arguments remain attacker-controlled. Recheck authentication and authorization at the data-access or mutation layer, return only the fields the UI needs, and keep RSC-capable framework packages on supported security-patched versions.

How Interviewers Score Your Answer

A Five-Day RSC Interview Practice Plan

Day 1: explain RSC, SSR, hydration, the RSC payload, and Server Functions without framework jargon. Draw the module graph created by 'use client'.

Days 2-3: split two real screens into Server and Client Components. Add Suspense boundaries, identify waterfalls, and state what crosses each serialized boundary. Use company-specific interview prep to choose scenarios close to your target loop.

Days 4-5: design cache keys and invalidation for public, private, and personalized data. Run one 45-minute mock where you explain security, degraded states, observability, and why RSC may not be the right choice. Add behavioral and leadership practice for senior ownership follow-ups.

Frequently Asked Questions

Are React Server Components stable?

React 19 treats the user-facing Server Components features as stable. React's framework and bundler implementation APIs do not follow semantic versioning across React 19 minor releases, so framework authors should pin compatible versions.

Do Server Components replace API routes?

No. They can read from a database, service, or API, but mature systems may retain APIs and a dedicated data-access layer for authorization, reuse, auditing, or organizational boundaries.

Do Server Components send zero JavaScript?

The Server Component's implementation is not shipped to the browser. Client Components, framework runtime code, and scripts used by the page still contribute JavaScript.

Is 'use server' the opposite of 'use client'?

No. 'use client' marks a client module boundary. 'use server' marks async Server Functions callable from client code; Server Components have no corresponding directive.

Final Takeaway

A strong RSC answer is a boundary decision, not a slogan. Explain what runs where, what ships to the browser, what can cross the protocol, when content reveals, which cache owns freshness, and where authorization is enforced.

Start with real Frontend Engineer questions on PracHub, answer one unseen scenario under time pressure, and review where your mental model broke. That practice builds the judgment an interview probes far better than memorizing another list of directives.

Official Sources

Technical behavior was checked on August 13, 2026 against React's official documentation for Server Components, 'use client' and serializable props, 'use server' and Server Function security, cache, and Suspense. Framework-specific examples were checked against the current Next.js documentation for Server and Client Components, data fetching and streaming, and Cache Components. Current security guidance was checked against React's RSC security advisory.