Cloudflare's product is not caching. Its product is being physically close to everyone, everywhere, at once — and then selling everything you can do with that position. Roughly one in five requests on the public web now passes through Cloudflare's network, which makes it one of the most leveraged companies in the history of infrastructure: a single organisation sits in the path of a fifth of humanity's web traffic, and the engineering decisions it makes each week reshape the experience of the entire internet.
Anycast is the whole trick
Everything Cloudflare does rests on one property that is almost too simple to believe: the same IP address is announced from hundreds of locations worldwide using BGP anycast. A packet addressed to that IP is delivered by the routing fabric to the topological nearest location announcing it. There is no DNS geolocation, no clever redirection, no request-level load balancing at the front — the network itself does the routing, and your packet lands in the closest point of presence.
That single property delivers the entire product portfolio at once. Low latency, because every user is close to a point of presence. DDoS absorption by dilution, because a flood spreads across hundreds of locations and each one can shed traffic. And a global deploy target, because code written once for the edge runs everywhere the network reaches. When you type an address that resolves to Cloudflare, you are not connecting to a server farm; you are connecting to whatever edge city is physically nearest you at that instant.
The moat is the network, not a feature list
From that position, Cloudflare layers an expanding stack of products that all share the same trick: caching and CDN, authoritative and recursive DNS, web application firewall rules, DDoS protection, load balancing, zero-trust access, and Workers — a runtime that executes your code at the edge, in hundreds of cities, from a deploy that is effectively global by default. The strategic coherence is the point. A company whose products all live behind the same anycast posture can offer a global WAF to a site that has never thought about regions, and a developer can deploy a Worker that runs everywhere without thinking about it twice. No competitor has the same combination of reach and control, because reach takes a decade and a hundred data centres to build.
The Workers runtime is worth pausing on, because it is the clearest expression of the anycast position. Instead of renting a server in a region and hoping your users are nearby, you deploy a unit of computation to the network itself: the same code runs in every point of presence, and each request executes in the location closest to the person who made it. That inverts the classic latency trade-off entirely — the compute comes to the user rather than the user reaching the compute. For a startup this is a kind of leverage no individual could build alone, which is exactly the point: Cloudflare's product is being physically close to everyone, and everything it sells is downstream of that fact. The caching is just caching; the position is the moat.
The blast radius problem
That leverage is a double-edged sword, and Cloudflare has paid for it in public, repeatedly. Anycast means a bad config push reaches every point of presence in seconds. It means a regular expression that backtracks badly can pin CPU worldwide at the same moment. And it means being the fallback for everyone leaves you with nobody to fail over to: when the network that protects a fifth of the web has a bad day, there is no second Cloudflare standing behind it.
- A bad config push reaches every point of presence in seconds.
- A regex that backtracks badly can pin CPU worldwide simultaneously.
- Being the fallback for everyone means you cannot fail over to anyone.
- A config file that crosses a hard-coded size limit can crash the routing software fleet-wide.
The incidents are instructive precisely because they are rare and self-inflicted. In 2019 a single bad config caused an outage that took the edge down; in June 2024 Cloudflare's own 1.1.1.1 resolver was blackholed by a BGP hijack that propagated through networks that did not filter routes; in November 2025 a configuration file that had doubled in size after a database query error tripped a hard-coded limit and crashed the traffic-routing software across the fleet, knocking a meaningful slice of the world's biggest sites offline for hours. In each case the failure was one shared dependency failing globally at once — geography does not make distributed infrastructure independent when every node runs the same logic. Redundancy only helps when the copies can fail independently, and Cloudflare's copies are famously identical.
Infrastructure this useful is also infrastructure this concentrated. Both things are true.
How the network is actually built
Underneath the products is a physical network that is unglamorous and enormous: hundreds of points of presence in over a hundred countries, connected by a backbone that carries traffic between them. Every point of presence contains the same modular design — generic commodity hardware, a shared layer of routing software, and a platform layer that runs the config, the caching, the firewall rules and the Workers runtime. That uniformity is a huge operational advantage: one version of the software runs everywhere, so features ship globally at once and behaviour is identical from Johannesburg to Tokyo. It is also, as the incidents show, the single greatest source of correlated risk.
The peering strategy deserves attention too. Cloudflare buys transit and also peers directly at hundreds of internet exchanges, which is how a company with no last-mile infrastructure can still be physically adjacent to every user: the networks that carry your traffic exchange it with Cloudflare as close to you as possible. The result is that being 'on Cloudflare' frequently means your packets never travel across a country at all — they exchange hands at your local peering point and arrive a few milliseconds later. Latency is not a feature of distance for these providers; it is a feature of who agrees to exchange traffic with whom.
There is a deeper lesson buried in the operations of the network, and it is about control. Because Cloudflare's whole position depends on its network being genuinely every-city, its operational culture is oriented toward the global blast radius: config changes are run through review, staged rollouts and canary points of presence, and the company has published detailed postmortems for every major incident. That transparency is partly brand, but it is also the rational behaviour of an organisation that knows its failures are measured in whole-internet units. When the load-bearing wall publishes its own crack reports, it is doing everyone a service — the rest of us just have to read them and design accordingly.
What Cloudflare's existence means for your architecture
If you use Cloudflare — and there is a good chance you do, whether you know it or not — the correct engineering response is not paranoia, it is a plan. Know that a single-vendor dependency on the edge is a dependency. Keep a secondary DNS provider genuinely configured and standing by, so a routing or resolver incident does not take your names offline. Consider a second provider or a direct-to-origin fallback for the pages that absolutely must work during a global incident. And use the access Cloudflare gives you to see your traffic: its analytics are a real-time map of what the world is doing to your site.
The uncomfortable truth the company's history demonstrates is that centralisation is efficient and resilience is expensive, and the whole internet chose efficiency. Cloudflare is not going away; it is the load-bearing wall of the modern web. The task for every engineer is to enjoy the benefits of that wall while remembering that it is load-bearing — and to design so that if it ever cracks, your users still have a door.
Spotted something I got wrong, or have an incident I should investigate? Write to [email protected].