You've seen singleflight collapse concurrent identical calls inside one process. But what happens when a thousand HTTP clients hit your CDN or reverse proxy at the same moment for the same uncached URL? Without help, each request becomes an independent origin hit. Request coalescing at the HTTP layer (also called "collapsed forwarding") solves this: the proxy holds the first request, queues the rest, and fans one response back to all of them.

NGINX calls it proxy_cache_lock. Varnish calls it "request coalescing" and does it by default. CloudFront calls it "request collapsing." Fastly, Akamai, and every serious CDN have a version. The mechanics are similar: keep an in-flight table keyed by cache key. If a request arrives for a key already in flight, park it on a waiter list instead of forwarding.

Real-world example. A news site posts a breaking story at 9:00 AM. The article URL isn't in cache. Within 2 seconds, 50,000 users click the push notification. Without coalescing, your origin gets 50,000 simultaneous requests for the same 200KB HTML page — instant CPU saturation, possibly a crash. With NGINX proxy_cache_lock on, the first request goes to origin; the other 49,999 wait (up to proxy_cache_lock_timeout). When the response returns and populates the cache, all waiters are served from cache. Origin load: 1 request instead of 50,000.

The knobs that matter:

• Lock timeout — how long a waiter will park before giving up and forwarding independently. Too short: coalescing fails under a slow origin. Too long: users see latency spikes when origin is genuinely slow.
• Cache key granularity — if your key includes headers that vary per user (cookies, Accept-Language), coalescing effectively disappears. Strip what you can.
• Negative caching — coalesce 404s and 5xxs briefly, or a broken URL becomes a stampede of its own.

Rule of thumb. If your origin's time-to-first-byte for a cache miss is T, and your peak concurrent request rate for a single hot key is R, coalescing reduces origin load by roughly a factor of R × T. A 500ms origin under 1000 req/s of the same key sees ~500× reduction. That's the difference between a healthy origin and a smoking one.

Where it breaks. Personalized responses (cookies, auth headers in the varied cache key) can't be coalesced — each request is genuinely different. Streaming/long-polling endpoints shouldn't be coalesced either; the "waiters" will time out before the first response finishes. Coalescing is for cacheable, shared, short-lived responses.