Subrequest Limits
Subrequest limits are caps imposed by edge and serverless platforms on how many outbound HTTP requests a single invocation can make. On Cloudflare Workers, each fetch to an upstream API counts as a subrequest, and plans define maximums per request.
Technical Architecture & Deep-Dive
Edge runtimes limit subrequests to keep shared infrastructure fair and prevent runaway fan-out. An aggregation pipeline calling three APIs uses three subrequests, which is well within limits, but loops that paginate through hundreds of pages can exceed them.
Good pipeline design keeps fan-out bounded, uses batch endpoints when providers offer them, and caches intermediate results so repeated invocations do not repeat the same upstream calls.
Key Architectural Benefits
Implement Subrequest Limits at the Edge
Deploy lightweight API aggregation, edge caching, and secret injection in minutes without Docker containers or complex servers.
Frequently Asked Questions
Q:Do cached responses count as subrequests?
Requests served from the platform cache API may count differently than network fetches. Check your provider documentation for exact accounting.
Related Architecture Concepts
Upstream Fan-out is an execution strategy where an edge gateway dispatches multiple HTTP subrequests to separate origin services concurrently rather than sequentially. The total latency is bound by the single slowest subrequest (max time) rather than the cumulative sum of all subrequests.
Edge functions are serverless code that executes in data centers distributed worldwide, physically close to end users, rather than in one central cloud region. They intercept HTTP requests to run logic like authentication, routing, caching, and response transformation with minimal latency.
API batch requests combine multiple operations into a single HTTP request, and the server returns all results together. Batching reduces the number of round trips and connection overhead, which is especially valuable for mobile clients and rate-limited APIs.