Modular Edge Computing for Multi-Tenant SaaS on Cloudflare Workers

The Monolith Problem at the Edge

Early edge deployments often start with a single, simple worker that gradually accumulates features like image optimization, routing, and header rewriting. This leads to an "edge monolith" experiencing issues similar to traditional application monoliths, but amplified due to the synchronous nature of edge execution. Key problems include deployment coupling, where all features share one release cadence; increased blast radius, where a bug in one feature can impact all tenants and features; platform limits on CPU and script size being shared unevenly; and ownership mismatch, leading to merge conflicts and slow iteration.

Modular Workers Architecture with Service Bindings

The proposed solution is a modular architecture using a thin gateway worker and multiple single-purpose feature workers. This decomposition is made cost-effective on Cloudflare by service bindings, which allow worker-to-worker communication within the same isolate on the same machine, eliminating the typical network latency associated with microservice calls.

• Gateway Worker: Handles composition (deciding which features apply) and cross-cutting concerns (request preparation, header hygiene, observability). It does not contain feature logic.
• Feature Workers: Each owns a single concern (e.g., image optimization, failover), its dependencies, test suite, and deployment schedule. They expose a cheap `shouldApply()` predicate for the gateway and the worker itself for execution via a service binding.

export default {
  async fetch(request: Request, env: Env, ctx: ExecutionContext): Promise<Response> {
    // Predicates run inline; only the heavy work is dispatched over a service binding.
    if ((await shouldServeFailover(request, env)).serve) return env.FAILOVER.fetch(request);
    const originRequest = prepareOriginRequest(request, env);
    const response = (await shouldOptimize(originRequest, env)).optimize
      ? await env.IMAGE_OPTIMIZER.fetch(originRequest)
      : await fetchFromOriginOrCache(originRequest, ctx);
    return shouldServeFailoverForResponse(request, response).serve ? env.FAILOVER.fetch(request) : sanitize(response);
  },
};

This pattern ensures that a feature's dependencies and CPU budget remain isolated, and failure in one feature worker does not bring down the entire request. To manage coordination and shared contracts, a monorepo strategy is adopted, where the gateway and feature workers coexist. This provides the ownership boundaries of separate services while maintaining the coherence of a single codebase.

Multi-CDN Realities and Architectural Implications

A crucial takeaway is that edge architectures are not easily portable across different CDN providers. The article contrasts Cloudflare Workers with Akamai EdgeWorkers, revealing fundamental differences in their execution and deployment models. Cloudflare Workers offer a single `fetch` handler owning the request end-to-end, enabling complex composition. Akamai, conversely, uses a property-based rules engine with EdgeWorkers invoked at specific lifecycle events, limiting their direct control over the request flow and requiring decisions to be propagated via request state and rules. This means porting a feature between such platforms often requires a complete re-architecture, emphasizing the need to consider platform primitives during initial design.