cloud-architecture-cloudflarelisted

# Cloudflare Architecture Knowledge Service-level detail for a Cloudflare-backed project. Pairs with Melvin's cloud-agnostic diagnostic checklist (traffic pattern, state location, SLAs, blast radius, cost explosion, coordination, limits, observability) — this pack supplies the Cloudflare-specific answers for each. Cloudflare's model is fundamentally different from AWS/Azure: there are no regions you provision into and no VMs — code runs in **V8 isolates** at the edge POP nearest the user, and state lives in purpose-built edge primitives. For concrete project topology, cost tiers, and stack context, read the architecture docs named in `CLAUDE.md`. ## Compute ### Workers (isolates) - **No cold starts.** Workers run as **V8 isolates**, not containers/VMs — a new isolate spins up in <5ms (often "zero" perceived) because there's no OS/runtime boot. This is the headline architectural difference from Lambda/Cloud Functions/Container Apps: the "scale to zero costs you a cold start" tradeoff that dominates AWS/Azure design simply doesn't exist here. Design for it — short-lived, stateless request handlers are ideal. - **CPU-time limit, not wall-clock.** The cap is **CPU time**, default **30s** on paid, configurable up to **5 minutes** (`limits.cpu_ms` in `wrangler.toml`, max 300000). Free plan is **10ms** CPU/request. Crucially, **time spent awaiting I/O (fetch, KV, D1) does not count** against CPU time — a Worker can wait minutes on a slow subrequest and burn near-