Next.js Request Deduplication: Architecting Global Coalescing Proxies

When we scaled our internal dashboard last quarter, we hit a wall with API throughput. We were firing identical fetch requests across multiple Server Components during a single page render, leading to database contention that spiked our p99 latency by roughly 350ms. While native tools help, true Next.js request deduplication requires a more robust architectural approach than just slapping cache() on everything.

The Limits of Native Memoization

You’re likely familiar with React.cache. It’s the bread and butter for preventing redundant data fetching in Next.js request memoization: stop over-fetching in server components. It works perfectly when the request lifecycle is predictable and contained within a single render pass.

However, we ran into trouble when our requests became non-deterministic. We had a scenario where multiple components triggered a heavy analytics fetch with slight variations in query parameters. Because React.cache keys are based on exact argument equality, we were still hitting our upstream service 10-15 times per request. We needed a way to coalesce these requests before they even left our server boundary.

Architecting a Global Coalescing Proxy

To solve this, we moved away from component-level memoization and implemented a global request-coalescing proxy using AsyncLocalStorage. By wrapping our fetch logic, we can track inflight requests and map similar, but not identical, requests to a single promise.

Here’s how we structured the proxy:

TYPESCRIPT
import { AsyncLocalStorage } from CE9178">'async_hooks';

const requestStore = new AsyncLocalStorage<Map<string, Promise<any>>>();

export async function coalescedFetch(key: string, fetcher: () => Promise<any>) {
  const store = requestStore.getStore();
  
  if (!store) return fetcher();

  if (store.has(key)) {
    return store.get(key);
  }

  const promise = fetcher();
  store.set(key, promise);
  
  return promise;
}

This pattern allows us to group requests that share a common identifier, even if they aren't triggered by the exact same function call. It’s a significant upgrade over standard Next.js dependency injection: managing scoped services in server components because it acts as a gatekeeper for network traffic.

Why Deterministic Deduplication Matters

In a distributed environment, "first-in-wins" isn't always enough. When you're dealing with Next.js server components: solving n+1 queries with dataloaders, you need to ensure that your deduplication logic is deterministic. If two components request the same data at the exact same time, you shouldn't just be memoizing—you should be coalescing.

We initially tried using a simple global object to track promises, but that caused memory leaks when the Node.js process stayed alive across multiple requests. Switching to AsyncLocalStorage ensured our request cache was scoped strictly to the current request lifecycle, preventing cross-user data leakage.

Performance Optimization Trade-offs

Is this overkill? Sometimes. If your application is small, stick to React.cache. But if you're building a dashboard where the same user context triggers dozens of API calls, implementing a coalescing layer is a necessary performance optimization.

We saw a reduction in upstream API load by about 40% after rolling this out. The trade-off is added complexity in your data-fetching layer and the need to be extremely careful with how you generate your cache keys. If your key generation is too loose, you risk serving stale or incorrect data.

FAQ

Does this replace React.cache? Not entirely. Think of React.cache as your first line of defense for identical calls. Use a coalescing proxy when you need to group similar requests or handle complex batching logic that cache() can't express.

How do you handle errors in coalesced requests? This is the hardest part. If the shared promise rejects, all callers receive the error. You need to implement robust retry logic before the promise is stored in the map, or ensure your fetcher handles transient failures gracefully.

Is this safe for Next.js 14+ with the App Router? Yes, but you must ensure your AsyncLocalStorage is correctly initialized in the request lifecycle. If you don't scope the store to the request, you will leak data between users, which is a critical security vulnerability.

Final Thoughts

We're still refining the key-generation strategy. Right now, we manually define keys based on a hash of the request parameters, but I'd love to move toward a more automated schema-based key generator. It’s messy, and it requires discipline, but when you're managing massive data requirements in Next.js server components, these architectural patterns are what keep the site responsive. Don't be afraid to pull the abstraction layer up from the component level when the performance gains are worth the engineering cost.