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 deployships 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.tomlfiles, 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.