Senior internals: RSC payload, caching layers, and production failure modes

After an RSC migration at Vercel, a customer’s TTFB regressed from 100ms to 2.5s. The component tree looked correct. The data fetching looked correct. The culprit: a Server Component that fetched 50 items in a sequential loop instead of Promise.all. A pattern that is invisible in code review but catastrophic in production.

The RSC Payload wire format

When React renders a Server Component tree, the output is not HTML and not JSON. It is the RSC Payload — a custom streaming format designed to be processed incrementally as it arrives over the network.

The format uses row-prefix codes:

• M — module reference (client component bundle URL)
• J — JSON literal (serialized props or data)
• H — hint (browser directive like prefetch)

Each row references previous rows by ID, building up the React tree incrementally. Example:

0:["$","div",null,{"children":[["$","h1",null,{"children":"Product"}]]}]
1:{"id":42,"name":"Product","price":29.99}

The browser’s React client processes these rows as they arrive, enabling the same “stream HTML, render what you have” behaviour described in the Suspense streaming lesson — but for React tree updates, not just initial HTML.

The RSC Payload is the mechanism behind Next.js client-side navigation: instead of fetching a new HTML page, the client fetches the RSC Payload for the new route and applies it to the existing React tree. This makes navigations feel instant because the shell (layout, nav) never re-renders.

Server Functions: type-safe RPC over HTTP

React 19 introduces Server Functions — async functions marked with 'use server' that can be called from Client Components but execute on the server. The framework generates a stable POST endpoint for each; the client-side call becomes a typed fetch.

// actions.ts
'use server';
export async function likePost(postId: string) {
  await db.post.update({ where: { id: postId }, data: { likes: { increment: 1 } } });
  revalidatePath('/posts');
}

// PostCard.tsx — Client Component
'use client';
import { likePost } from './actions';
export function PostCard({ postId }) {
  return <button onClick={() => likePost(postId)}>Like</button>;
}

TypeScript sees likePost as a normal typed function. No need to define a REST route, request/response types, or error handling shape. Arguments are serialized automatically; the function body never ships to the client.

Combined with form actions (<form action={serverFunc}>), Server Functions enable progressive enhancement: the form works with JavaScript disabled because the browser submits to the generated endpoint directly.

Constraints: arguments must be serializable (no class instances, no functions). Authentication must be explicit inside the function — the framework does not automatically check session cookies. Never trust client-provided IDs for ownership checks without re-validating server-side.

Caching layers and coordinated invalidation

A modern Next.js 15 app has at least five caching layers:

1. CDN edge cache — URL-keyed, seconds to hours. Serves static content without hitting origin.
2. Next.js fetch cache — RSC fetch() calls are cached by default with a configurable revalidate duration.
3. Database query cache — Redis or in-memory, sits in front of the database.
4. Browser HTTP cache — controlled by Cache-Control headers.
5. Client library cache — TanStack Query / SWR, keyed by queryKey.

A mutation that changes data must invalidate the right layers:

// On the server (Server Function or route handler)
revalidatePath('/products');      // Next.js cache + CDN if configured
revalidateTag('product-42');      // granular tag-based CDN purge

// On the client
queryClient.invalidateQueries({ queryKey: ['product', 42] });

Skipping any layer leaves users staring at stale data. The most common bug: the server cache is revalidated but the client TanStack Query cache still serves the old response for the next 5 minutes.

Hydration mismatches: silent interactivity bugs

React’s hydration assumes the server-rendered DOM exactly matches what the client would render given the same props. When they differ, React’s reconciler tries to patch the DOM, but its model of which event handlers belong to which DOM nodes is now inconsistent — clicks may fire on the wrong handler or be silently dropped.

Common causes:

• Date.now() or Math.random() rendered on both sides — different values
• Conditional rendering based on window.innerWidth — server has no window
• Reading localStorage at module top-level

The visible output looks correct because both server and client render valid HTML. But the event-handler bindings are misaligned.

Fix patterns:

• useEffect for client-only logic: render the safe initial state on both sides; mutate to client-specific state after hydration completes
• suppressHydrationWarning: valid for genuinely divergent leaves (timestamps with locale)
• Client Components for content that is fundamentally client-specific

React 19 improved hydration error messages to localise the mismatched element; pre-19, the message was generic. Production teams instrument hydration errors via error boundaries reporting to Sentry — a steady non-zero rate signals accumulating mismatches before they surface as user-reported bugs.

Edge runtime for data fetching

The edge runtime (Next.js Edge, Cloudflare Workers, Vercel Edge) runs server code at CDN nodes instead of a central data center. Latency to the user: single-digit ms vs hundreds for traditional servers.

Best fit: globally-replicated data sources (Cloudflare D1, Turso, PlanetScale) where the edge server fetches from a nearby replica. Edge-rendered RSC gives the user first paint in 50–100ms regardless of geography.

Constraints: limited APIs (no Node.js fs, no native modules), Web-standard APIs only (fetch, crypto.subtle), smaller memory limits per request.

Real production failures

Vercel 2024 — server-side waterfall: A customer’s RSC migration regressed TTFB from 100ms to 2.5s. Root cause: a Server Component fetched 50 product items in a sequential for...await loop instead of Promise.all. Caught by observability dashboards flagging the p95 TTFB spike; fixed by wrapping in Promise.all. The lesson: sequential await in Server Components is a server-side waterfall with the same cost as client-side — it blocks the Suspense boundary from streaming.

Spotify Web Player 2023 — incomplete optimistic snapshot: An optimistic update for “add to playlist” used setQueryData but the onMutate did not snapshot the previous state. When the server rejected the request, the rollback set the cache value to undefined instead of the actual previous state — playlists appeared to vanish for a few seconds. Fixed by the canonical pattern: always call queryClient.getQueryData in onMutate before the optimistic update.

Linear 2024 — SSE reconnect message loss: A Server-Sent Events based real-time sync used a client-generated message ID scheme. On reconnect, the client missed messages sent during the disconnect window — users saw cards “bounce back” after drag operations. Fixed by using server-assigned monotonic IDs and a Last-Event-ID-based resume protocol that the server replays missed messages for.