Architecture: ownership along one request
Understand the Cloudflare request lifecycle through responsibility boundaries, data flow, and failure ownership.
Edited and verified by Orange Book Editorial Team ·
An architecture page answers “who owns this part?” rather than repeating procedural steps. The diagram shows one primary request flow; DNS management, asynchronous logs, and cache tiers belong in focused diagrams.
Detailed description
- 01Client boundary
Owns intent, method, URL, and client-side caching.
- 02DNS boundary
Owns name resolution and proxy entry selection.
- 03Edge boundary
Owns TLS, rules, security, and cache evaluation.
- 04Compute boundary
Worker code owns application-level edge logic.
- 05Origin boundary
Owns source data and compute not completed at the edge.
Key architecture decisions
| Decision | Default | Change it when |
|---|---|---|
| Run a Worker? | Add it only for application logic | Authorization, rewriting, aggregation, edge API |
| Fetch the origin? | Respond directly when possible | Source data, dynamic rendering, or writes are required |
| Cache? | Start from freshness and privacy | Data is public, reusable, and has an invalidation plan |
| Own a failure? | Place it with evidence | Never use “Cloudflare is broken” as a diagnosis |
Runtime boundaries are not plan guesses
Free limits that directly affect this deployment architecture
Cloudflare can change plans and limits; reopen the primary source before implementation.
| Product / plan | Current fact | Scope and caveat |
|---|---|---|
| WorkersWorkers Free | Dynamic requests100,000 requests / day | Resets daily at 00:00 UTC; static asset requests are excluded. Verified · Source updated Primary source |
| WorkersWorkers Free | HTTP request CPU time10 ms / invocation | Time waiting on network, KV, or database I/O is not CPU time. Verified · Source updated Primary source |
| WorkersWorkers Free | Compressed Worker size3 MB (gzip) | Use the gzip size reported by a Wrangler dry run. Verified · Source updated Primary source |
An arrow is not a deployment guarantee
A Worker can return directly and does not have to visit the origin. The diagram shows an allowed primary path; logs, headers, and tests establish what a real request did.
Architecture review checklist
- Does every node have one clear responsibility?
- Is Worker failure fail open or fail closed, and does that match the security goal?
- Does the origin trust only expected entry points, and does sensitive data cross unnecessary boundaries?
- Have cache state and application state been treated as different concepts?
For cache anomalies, use the cache-status runbook.
Primary sources
Did this page help you complete your goal?
Beta feedback is generated in this browser and is never uploaded automatically.