Article: Modular Edge Computing at Multi-Tenant SaaS Scale on Cloudflare Workers

The edge platform that was built was the starting point for the web traffic of hundreds of thousands of tenant accounts in a multi-tenant SaaS system. Beginning as a simple Cloudflare Worker with one fetch handler and one route, the system grew in complexity over time as it accumulated responsibilities such as image optimization, failover pages, routing, header and cookie rewriting, and per-tenant config lookups.

Each of these responsibilities was owned by a different team, leading to a shared monolith that every team edited and no team owned. This issue is amplified at a large scale, as each tenant account is an independent customer with its own configuration and isolated from the rest, requiring the system to run on more than one content delivery network (CDN).

At the edge, a millisecond added to the request path is paid across the whole base, making edge performance crucial. With one worker in the synchronous path of every request for all tenants, a millisecond added there results in a millisecond paid across the entire customer base. This issue is further compounded by the fact that a single worker is deployed, and any change to the script requires redeploys for the entire system, collapsing each team's cadence into one shared cadence set by the slowest change.

The article suggests a fix that keeps the edge's lean entry point while allowing every team to own, test, and deploy on its own schedule. This fix involves splitting the monolith into multiple feature workers, each owning exactly one concern and its own dependency bundle, test suite, and deployment. A thin gateway worker is placed in front of these feature workers, responsible for composition and cross-cutting concerns that apply to every request, such as request preparation, header hygiene, and observability.

The gateway does not own feature logic, allowing each feature worker to have high cohesion and low coupling with the others. The gateway's contract with each feature worker is defined by a cheap shouldApply() predicate, which the gateway imports and runs inline. This design allows for independent feature deployment and resilience, as a feature worker's error or timeout will not affect the entire request.