Build1 publisher2 min readPublished
One edge worker in front of hundreds of thousands of tenants makes every deploy all-or-nothing
An InfoQ account of a multi-CDN edge platform describes splitting one Cloudflare Worker into a gateway plus feature workers over service bindings, after the shared script tied every team's cadence to the slowest change in flight.
The Engineer · Build desk
What happened
- The edge platform described at InfoQ fronts web traffic for hundreds of thousands of tenant accounts and began as one Cloudflare Worker with a single fetch handler and one route.
- That one entry point accumulated image optimization, failover pages, routing, header and cookie rewriting and per-tenant config lookups, each of them mostly owned by a different team.
- The author's fix is a gateway worker calling separate feature workers over service bindings, which the article says decouples teams and blast radius without adding a network hop.
- The platform is globally distributed and runs on more than one content delivery network, so every edge feature has to work on each of them.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- exposure Because the worker is the request path and not a replaceable instance behind a load balancer, a bad regular expression or a hot loop in one feature takes down every feature for every tenant at the same time.
- constraint Any latency a single team adds is charged to every request for every account, so performance work at the edge is a shared budget that no team controls alone.
- decision Keeping a single live version at this tenant count makes each release a bet on the whole customer base, so per-account versioning has to be built before the split is worth much.
- cost Letting independent teams deploy into a shared request path is paid for in test infrastructure: unit suites for every feature worker, integration tests at the gateway and synthetic monitoring in production.
Separate modules inside one script would fix the merge conflicts and none of the limits. Workers run under hard ceilings: a fixed per-request CPU budget and a cap on script size. Each feature's dependencies inflate the shared bundle and lengthen parsing and startup work in the hot path, even for requests that touch none of that code [7]. Separate deployables mean a request that only rewrites a header stops paying to load the image pipeline. The article does not give the values for either ceiling [15].
With one worker there is one deployment. A one-line header fix waits behind a half-finished experiment and the two ship together, and a rollback of one feature is a rollback of all of them [5]. The features also change at different rates. Failover logic should change rarely and an image pipeline wants to iterate fast. Forcing both through one file, the article says, produces merge contention, unclear ownership and "fear-driven development, where nobody dares touch the file for fear of what else they will break" [13].
Image optimization is the worked example of the build-or-buy call. A CDN's zone-level toggle is too coarse for multi-tenant SaaS, so format negotiation across AVIF, WebP and legacy formats, device-aware sizing and per-tenant opt-out get built inside the workers instead [8]. Tenant-level control is what that buys. The cost is that you own an image pipeline, and on a platform fronting more than one CDN you own it twice. According to the author, Akamai's and Cloudflare's execution and deployment models differ enough that porting a feature is re-architecting it. Parity has to be held continuously [9].
Whether the split pays somewhere else turns on configuration granularity; tenant count alone does not settle it. If every tenant can live with one zone-level setting, the toggle is cheaper than owning a pipeline [8]. The split is worth its cost when the configuration is per account and a release has to reach accounts in stages [10]. In my view the versioning is the harder half to retrofit. A platform built on the assumption of one live script has that assumption in its routing and its config lookups as well as its deploy step [3]. At single-site scale, the article says, you can live with the monolith [14].
What to watch
- Before-and-after CPU time per request and bundle size would test the ceiling argument the article makes without numbers.
- A published account of the Akamai build would show how much of the gateway design survives the port.
- Whether per-account version pinning gets platform support from the CDNs or stays application-level plumbing in the gateway.