ISR revalidate=0 vs swr>0: which setting avoids stale pages under concurrent traffic?

I am configuring Incremental Static Regeneration for a product listing route in Next.js (App Router, deployed with next start) and need to pick between two documented approaches: setting revalidate to a low value so pages regenerate frequently, or keeping a longer revalidate and relying on the stale-while-revalidate window to serve the previous page while regeneration happens in the background.

The constraint is burst traffic: many requests can hit the route within the same revalidation window. My understanding is that with the default stale-while-revalidate behavior, requests arriving during regeneration may still receive the older cached page until the new render completes, and that per-route cache settings such as fetchCache and mismatched cacheMaxAge/swr values can extend staleness beyond the intended window. I am unsure how the two approaches differ in practice for this concurrency pattern, and whether next start versus a platform-managed deployment changes the answer.

Which approach guarantees the shortest observable staleness under concurrent requests: a short revalidate interval, or a longer interval with an explicit stale-while-revalidate configuration? What response headers (for example Cache-Control, Age, or X-Nextjs-Cache) should I inspect to verify which behavior is actually in effect? Are there documented cases where concurrent requests during regeneration cause some visitors to receive different page versions?