Latency spikes under concurrent requests when Nuxt 3 routeRules cache expires

Short answer

There is no fixed concurrency number. On Nuxt 3 (3.8 or newer, Node server preset, Nitro routeRules cache, no coalescing), every request that arrives while an entry is expired and not yet repopulated runs the route handler again. The threshold is set by two measurable variables: the handler's uncached execution time and the request arrival rate inside the expiry window.

Planning estimates only, not measured facts: handlers that finish in under roughly 50 ms typically need hundreds of simultaneous requests before redundant executions saturate the event loop, while handlers taking hundreds of milliseconds to seconds can spike at tens of concurrent requests, because the vulnerable window is wide enough for misses to pile up. Treat both ranges as hypotheses for your own load test.

What staleWhileRevalidate changes

With swr enabled, a request that hits an expired-but-stored entry receives the stale payload immediately while a background refresh updates the cache. Clients stop seeing the spike, but the server still pays for at least one full handler execution, and the request that triggers revalidation still incurs the full latency.

• Protection breaks down when revalidation takes longer than the gap between expirations or arrivals: if a refresh takes 5 s while requests keep arriving, further background refreshes can start before the first one finishes, because Nitro's routeRules cache has no built-in distributed lock.
• Storage matters. Memory storage is per-process, so multiple workers or instances each hold their own entry and can stampede independently; a shared driver such as Redis changes what a single refresh means and should be verified on your locked Nitro version.

Starting values for maxAge and swr

Both options take seconds. Size them from measurements, then verify:

Option	Starting point	Rationale
maxAge	Longest staleness the content tolerates (60 s for near-real-time, 300–600 s for slow-changing pages)	Fewer expirations mean fewer stampede windows
staleWhileRevalidate	Several multiples of the handler's uncached p95 (a p95 of 500 ms suggests 10 s)	The window must cover one full revalidation under load

// nuxt.config.ts
routeRules: {
  '/heavy/**': {
    cache: {
      maxAge: 60,               // seconds
      staleWhileRevalidate: 10  // seconds
    }
  }
}

Verify before tuning further

Run a ramped load test timed to hit just after expiry, and count handler executions per expiry window with a log line or counter inside the handler.

import http from 'k6/http';
import { sleep } from 'k6';

export const options = {
  stages: [
    { duration: '30s', target: 50 },
    { duration: '60s', target: 200 }
  ]
};

export default function () {
  http.get('http://localhost:3000/heavy-page');
  sleep(0.1);
}

Watch p95 and p99 latency, CPU, and executions per expiry. With swr on, roughly one execution per window means the window is holding; a count that climbs with concurrency means the swr value is too short or revalidation is too slow for the traffic pattern.

The detail that changes the recommendation

What is the handler's uncached p95 latency, and what does it call downstream? That number sets both the concurrency level where the spike appears and the minimum swr worth testing. Cache internals have shifted across Nitro releases, so confirm this behavior on your locked version before committing to values.