Single Cloudflare Worker — no Service Bindings

ADR-006: Single Cloudflare Worker — no Service Bindings

Status: Accepted Date: 2026-04-06 Deciders: Mishaal Murawala

Context

CF Workers supports multi-Worker architectures via Service Bindings (Worker A calls Worker B with zero-latency RPC). We needed to decide whether to split the gateway into multiple Workers (e.g., auth Worker, API proxy Worker, MCP Worker) or keep everything in one.

Decision

We will use a single Cloudflare Worker with Hono.js route groups (/mcp, /api, /admin, /health, /slack/events, /webhooks/*, /connect, /schedule).

Consequences

Positive

• One deployment unit — wrangler deploy ships everything
• Shared bindings (KV, D1, DO, R2) without cross-Worker binding configuration
• No inter-Worker latency
• Simpler debugging — one set of logs, one tail command
• Route groups provide logical separation without physical separation

Negative

• Single Worker has a 128MB memory limit (V8 isolate). All routes share this budget.
• A bug in one route group can crash the entire Worker
• No independent scaling per route group

Risks

• If a single API handler loads too much data into memory, it OOMs the entire Worker. Mitigated by the 30s timeout and fail-fast pattern — no handler should hold large datasets.

Alternatives Considered

Multi-Worker with Service Bindings

• Rejected because: adds deployment complexity (multiple wrangler.toml files, binding configuration, versioning), and the gateway’s workload doesn’t justify it. Each request does: auth check (KV read) → token lookup (KV read) → outbound fetch. This is lightweight enough for one Worker.

Microservices on containers (Docker/ECS)

• Rejected because: the entire V5 rationale is edge-native, sub-10ms overhead. Containers add cold start, networking, and operational complexity.