1. Executive Summary & Scale Metrics
Cloudflare is not a traditional web application; it is the global shield and edge execution fabric that sits in front of approximately 20% of all websites on the internet.
Global Edge Network & DDoS Mitigation Scale
CloudflareEdge performance metrics across 330+ cities and 20% of the web
The fundamental physical constraint Cloudflare solves is the speed of light and network transit latency: establishing a secure TLS 1.3 connection from Sydney to an origin server in London requires multiple trans-oceanic round-trips taking over 600 milliseconds before a single byte of HTML is received. Cloudflare intercepts the connection in Sydney in < 5 milliseconds, absorbs massive DDoS attacks at line-rate, and executes serverless code at the edge.
2. Requirements & Production Constraints
Functional Requirements
- Global Reverse Proxy & CDN: Intercept, decrypt, inspect, cache, and accelerate HTTP/1.1, HTTP/2, and HTTP/3 (QUIC) traffic for millions of customer domains.
- Autonomous DDoS Mitigation: Automatically detect, absorb, and drop volumetric (L3/L4 SYN floods) and application-layer (L7 HTTP floods) attacks without customer downtime.
- Serverless Edge Computing (Cloudflare Workers): Execute user JavaScript/TypeScript and WebAssembly at the edge with near-zero cold start latency.
- Origin Shielding & Tiered Cache: Minimize cache misses hitting the customer's origin infrastructure.
Non-Functional Requirements & The Speed of Light
- The Speed-of-Light Barrier: Photons in fiber travel at roughly
frac{2}{3} c ≈ 200,000 km/s. Routing around the globe takes time that no software optimization can bypass. Connections must terminate physically close to the user. - Sub-Millisecond Cold Starts: Traditional container-based serverless (AWS Lambda running Docker micro-VMs) has cold start times of 150–800ms. An edge proxy executing on every HTTP request must start in < 1ms.
- Zero Connection Disruption on Server Reboots: Hardware updates in edge data centers must not drop active TCP/QUIC connections.
3. The Naive Design & Why It Collapses
NAIVE APPROACH: UNICAST DNS GEOLOCATION ROUTING
[User in Sydney] ── DNS Lookup example.com ──> [Geo-DNS Server]
│
▼ (Returns Sydney Server IP: 192.0.2.1)
[Attacker in Russia] ── Floods 192.0.2.1 with 800 Gbps DDoS ──> [Sydney Server Melts!]Why Unicast Geo-DNS & Docker Serverless Collapse Under Edge Scale
CloudflareThree fatal flaws that create DDoS vulnerability and sluggish edge execution
DDoS Target Concentration & Pipe Saturation
criticalIn Unicast routing, each regional data center has a distinct IP address. An attacker can target a single IP with 800 Gbps of traffic, completely overwhelming that specific facility's transit pipes.
DNS Cache Propagation Failover Delays
criticalIf a server crashes, updating DNS records to point to an alternate server takes hours because global ISP resolvers cache DNS TTLs, causing prolonged outages.
Docker Container Cold Start Latency Overhead
highBooting micro-VMs or Docker containers takes 150ms to 800ms, making per-request serverless edge computation impossibly slow.
4. Deep Architecture: Layer-by-Layer Walkthrough
Cloudflare solves this with BGP Anycast Routing, eBPF/XDP Kernel DDoS Shields (Gatebot & Unimog), Tiered Caching, and V8 Isolate Serverless Workers.