Summary

  • Request collapsing can smooth a surge for the same eligible object by sharing one origin fetch. It also puts clients on a waiting list.
  • If that fetch yields neither a reusable response nor a hit-for-pass marker, later requests can rebuild the queue and proceed consecutively rather than concurrently.
  • Accept reduced origin work together with safe response reuse, delivered outcomes and bounded waiting. A lower request count alone proves neither savings nor a better service.

A quieter origin can have a noisy audience

A popular object expires at the edge. Requests arrive together, but the origin sees fewer fetches than it would if every client went there separately. That can be a genuine improvement: duplicate work has been combined. It can also be an incomplete picture. The clients whose requests were combined still need a useful response, and some may be waiting behind work that cannot satisfy them.

Fastly calls the mechanism request collapsing. Its documentation describes combining concurrent requests for the same object into one request to origin, then potentially using the resulting response for the pending clients. The word potentially matters. Sharing an in-flight fetch does not establish that its response is suitable for everyone attached to it.

For a buyer, this makes origin offload an input to acceptance, not acceptance itself. Fewer fetches can protect expensive or limited origin resources. They do not alone demonstrate completed delivery, acceptable waiting, safe information reuse or a lower total invoice. This article measures none of those customer outcomes. It examines the supplier’s published mechanisms that make them distinct.

The waiting list is part of the benefit

Without collapsing, simultaneous demand for a newly uncached popular object can produce an origin stampede. Fastly’s waiting list lets a later eligible request attach to a fetch already in progress instead of starting another one. If the response is reusable, the shared work can serve the waiting clients.

The benefit is real in the mechanism: fewer repeated origin operations and a smoother load shape. But the queue also concentrates waiting on the progress of one fetch. Its value depends on what comes back, how quickly it becomes usable and which clients may properly share it.

This is not a claim that every matching URL joins one global queue. Eligibility belongs to the relevant cache object and variant within the applicable delivery path. Fastly’s discussion of hit-for-pass explicitly notes that variants governed by Vary can behave differently at one cache address. A visible URL is not sufficient evidence that different users should receive the same response.

The buyer therefore needs a content boundary, not merely a graph of total traffic. A public asset and a user-specific response can arrive under superficially similar demand. Their legitimate reuse is different. That distinction must survive the desire to reduce origin work.

When the queue cannot share its result

Fastly documents a difficult branch. A request collapses, but the origin returns a response that cannot be used for the waiting clients, and no hit-for-pass marker can be created. The next request goes to origin and the remaining requests can form a new queue behind it. If the same conditions recur, origin requests proceed consecutively rather than concurrently.

The guide warns that some such situations can produce waits of several minutes. This is a published possibility, not an observed incident, a forecast for a customer or an unavoidable result of every private response.

The VCL reference makes one condition especially clear. When beresp.cacheable is false, the response is not stored and a hit-for-pass object is not created, even if response processing ends in deliver. Secondary requests may be released only to form another queue.

An origin count alone misses the distinction between effective combination and this bottleneck. In the successful case, one fetch finishes useful work for several clients. In the difficult case, the count can stay modest while unfinished requests accumulate. Low origin activity need not mean that demand has been efficiently served.

Nor should this branch be used to justify caching private information. The same reference warns that setting the cacheability flag true can cause otherwise uncacheable responses to be cached. Making an unsafe response shareable is not an acceptable way to improve a queueing metric.

A marker is not a shared private response

Hit-for-pass provides a different mechanism. It places a marker in cache telling requests not to collapse for that resource or variant. Requests encountering the marker go to origin separately. In the documented CDN VCL pass-on-response path, a cacheable response-processing state can establish the marker without reusing the response payload for the waiting clients.

The distinction is subtle but commercially important. A cache entry can record that work should remain separate rather than hold content to share. It is not evidence that private response bodies have been cached for other users.

Fastly also distinguishes pass on request: if a request is marked to bypass the cache before the origin fetch, it is not eligible for collapsing. Knowing that work will not be reusable can therefore matter before a waiting list is built. The applicable interface and response-processing conditions still need to be understood; VCL-specific controls are not a universal description of every Compute cache interface.

These alternatives do not abolish demand. Separate requests shift work back to the origin, potentially concurrently. An origin that cannot support that workload has not acquired capacity merely because a queueing branch has changed. The acceptance question joins safe reuse to the ability to complete the remaining separate work.

Persistence and in-flight reuse are different

Fastly’s collapsing guide describes another case: a response not marked private may satisfy already waiting clients even with max-age=0 or no-cache, while the next request misses again. Within that guide’s waiting-list discussion, a response need not remain a fresh stored object for later arrivals to be useful to clients already waiting.

That is not a blanket equivalence between HTTP directives, nor permission to share a user-specific response because its freshness lifetime is zero. It also must not be confused with the VCL condition in which beresp.cacheable is false. Response privacy, reuse eligibility, stored freshness and the waiting-list branch are separate facts.

The supplier’s demystification blog defines a usable-object metric in terms of cacheability and positive remaining cache lifetime. That metric should not be silently mapped to every waiting-list delivery case described elsewhere. A label is useful only when its counted condition remains explicit.

Streaming miss adds a timing distinction. When enabled, usable response data can begin entering cache once origin response headers arrive, narrowing the period during which new requests overlap the originating fetch. Less measured collapsing can therefore accompany a faster, efficiently handled origin response. Frequency alone does not identify success or failure.

Removing a queue can remove another option

The CDN VCL control req.hash_ignore_busy is not just a queue switch. Fastly documents that enabling it makes requests ineligible for collapsing while leaving them eligible for a fresh cache hit. It also makes stale objects unusable, disabling the effects of stale-while-revalidate and stale-if-error.

This differs from pass on request and can alter an availability option as well as origin concurrency. Treating it as a harmless way to remove waiting would omit a consequential part of the control surface.

Serving older content has its own boundary. Fastly’s stale tutorial describes conditions and windows under which stale responses may be used, including origin problems. That does not mean every error automatically falls back to stale. It also does not establish that older permissions, inventory or prices are acceptable to serve. The legitimate freshness requirement belongs to the application and its users.

Accept useful delivery, not a smaller number

A practical decision record can identify the content class, actual cache identity and variants, authorized reuse, applicable service interface, failure branch, and tolerable waiting and freshness. This is an editorial recommendation, not a required Fastly feature or an audit of a customer’s configuration.

The monitoring question is correspondingly precise. Did a lower origin count accompany more completed useful responses with acceptable waiting, or did clients collect behind an unusable result? Were separate responses kept separate without simply transferring an unsustainable burst to the origin?

No customer account, service, cache or VCL setting was changed or tested for this article. The commercial conclusion follows only as a bounded acceptance principle: request collapsing is valuable when shared work completes legitimate delivery. Its benefit should be evaluated together with the waiting and reuse boundary that makes that delivery possible.

Sources