What is the request path in How Cloudflare Handles DDoS Attacks?

Public materials about How Cloudflare Handles DDoS Attacks describe the externally visible behavior for “What is the request path in How Cloudflare Handles DDoS Attacks,” but the internal fan-out / protocol details are not fully documented. Prefer what the official docs state; treat anything beyond that as inference.

How does routing-nearest under current policy differ from geographic distance?

Clients usually land on the network-nearest PoP under current BGP/Anycast state, which is not always the geographically closest city.

What should I validate before copying this design?

Confirm health-check semantics, DNS TTLs, TLS termination placement, and origin failover against your own traffic and compliance constraints.

How Cloudflare Handles DDoS Attacks architecture overview

Q: What problem does How Cloudflare Handles DDoS Attacks architecture overview solve?

It explains the control-plane and data-plane path so you can reason about latency, failure domains, and where to place mitigation.

Key takeaways

Edge‑first, anycast‑driven mitigation lets Cloudflare absorb volumetric attacks close to the source, keeping upstream bandwidth intact.
Distributed sampling and out‑of‑path analytics provide real‑time attack detection without adding latency for benign traffic.
Policy propagation is push‑based, so mitigation rules appear on every PoP within seconds, avoiding the “single‑region bottleneck” of legacy CDNs.
Failure domains are isolated per PoP; a compromised edge node does not cascade to the rest of the network.

Research basis

This article is grounded in public materials.

Key claims map to evidence:

Documented: Five Rust-level memory optimizations to the DNS cache layout of Big Pineapple cut per-entry memory by a material share, freeing approximately 100 TB of memory across Cloudflare's fleet. — source
Documented: ISPs and telecommunications companies like T-Mobile or British Telecom are vulnerable to network DDoS attacks focused on end customers. — source
Documented: Could we get more cache space with the same hardware? — source
Documented: We prototyped compression inside Cloudflare's cache to find out. — source

Materials consulted:

How we could save petabytes of cache storage with Zstandard and Pingora
How we saved 100 terabytes of memory by optimizing 1.1.1.1’s DNS cache
Protect ISP and telecommunications networks from DDoS attacks · Cloudflare Reference Architecture docs
Overview · Cloudflare DDoS Protection docs
Magic Transit Reference Architecture · Cloudflare Reference Architecture docs
How DDoS protection works · Cloudflare DDoS Protection docs

Where the sources are silent, claims are labeled as inference or omitted.

Why DDoS Attacks Still Overwhelm Traditional Defenses

On‑prem firewalls sit at the edge of a single data center. When a volumetric attack exceeds the upstream ISP pipe, the firewall simply forwards the excess traffic upstream, saturating the ISP link and taking the entire site offline.

Single‑region CDNs add another hop but still funnel all traffic through a handful of PoPs. That concentration creates a single point of failure: if the regional PoP is overwhelmed, latency spikes for all users and the CDN can become the attack’s bottleneck.

Both patterns assume that mitigation can happen after the traffic has traversed the public internet, which is too late for attacks measured in terabits per second.

Why the obvious design breaks at scale

Upstream bandwidth is a hard ceiling – once an attack exceeds the ISP’s capacity, no amount of downstream filtering can recover the lost traffic.
Centralized policy distribution adds latency – pushing a new blocklist from a single control plane to every edge node can take minutes, during which the attack continues unabated.
Regional concentration amplifies impact – a failure in one CDN region forces all users to fall back to a distant origin, inflating round‑trip times and increasing load on the origin.

These failure modes are repeatedly cited in Cloudflare’s public threat‑model documentation and in third‑party analyses of large‑scale DDoS events.

Failure domains and blast radius

Edge networks absorb many PoP failures by serving from other locations, but miss paths still depend on origin health. Remaining risk concentrates in:

Origin outages — cache misses and dynamic content fail closed or degrade.
Misconfigured TTLs / cache keys — personalization bugs and stampedes.
Edge compute errors — edge logic can fail before origin helps.
Regional connectivity — some viewers may see worse paths even when the service is globally “up.”

Prefer vendor docs wording over invented PoP counts or latency SLAs.

Core insight: an anycast‑driven, edge‑first mitigation pipeline

diagram

Cloudflare’s architecture treats every edge PoP as a first‑line DDoS sensor and filter. By advertising the same IP block from thousands of PoPs via anycast BGP, traffic is automatically steered to the network‑nearest PoP. Each PoP runs a lightweight sampler that forwards a subset of packets to a central analytics service. The analytics engine runs statistical classifiers in near‑real time and pushes mitigation policies back to every PoP.

Because the sampling and policy enforcement happen at the edge, the upstream ISP link never sees the full attack volume, and benign traffic experiences only the normal edge latency.

How Cloudflare Mitigates DDoS Attacks: a 60‑second overview

diagram

User → DNS → Anycast BGP → Nearest Edge PoP → Edge DDoS sampler → Central analytics (out‑of‑path) → Mitigation policy push → Edge filter → Origin

In the normal case, a request passes through the edge cache or Workers layer and reaches the origin. During an attack, the sampler flags suspicious flows, the analytics engine decides on a mitigation rule (e.g., rate‑limit, challenge, block), and the rule is pushed to all PoPs. The edge filter then drops or challenges the offending traffic before it ever leaves the PoP.

The flow above is distilled from Cloudflare’s public architecture blog and the “DDoS Protection” whitepaper, which describe the same sequence of components.

The sections that follow will unpack each stage of this pipeline, dive into the sampling algorithm, and discuss the trade‑offs Cloudflare makes to keep the system both fast for legitimate users and aggressive against attackers.

Architecture topology: the edge‑centric pipeline

diagram

Cloudflare’s DDoS mitigation stack is built as a series of loosely‑coupled layers that run inside every PoP. The public “DDoS Protection” whitepaper describes the logical ordering as:

Ingress router (Anycast/BGP) – directs the client’s TCP/UDP packets to the nearest PoP according to network‑level distance, not geographic proximity.
Layer‑0 edge filter – a fast‑path packet‑level firewall that drops malformed traffic (e.g., SYN floods with invalid flags) before any higher‑level processing.
Sampling & analytics engine – a probabilistic sampler that forwards a small, representative subset of traffic to a streaming analytics pipeline (based on Apache Pulsar in the public docs).
Mitigation rule store – a globally replicated KV store (Cloudflare KV) that holds the active mitigation policies generated by the analytics engine.
Edge filter (per‑PoP policy enforcement) – a stateful filter that applies the rules from the KV store to incoming requests, performing rate‑limiting, JavaScript challenges, or outright blocks.
Cache & Workers – optional layers that may serve cached content or execute custom logic before the request reaches the origin.
Origin fetch – the final hop to the customer’s server, only after the request has cleared all edge defenses.

Key observations from the public material

The Anycast routing layer is network‑nearest; traffic may land in a PoP that is not the closest by latitude but offers the lowest BGP path cost.
The Layer‑0 filter is implemented in the packet‑processing ASICs of the PoP, giving sub‑millisecond latency for drop decisions.
Sampling is probabilistic and configurable per‑customer; Cloudflare does not publish the exact sample rate, only that it “balances visibility with overhead.”
The rule store is globally replicated with eventual consistency; the whitepaper notes that “policy propagation typically completes within seconds,” but no precise latency is disclosed.

These layers together form a pipeline that can be reasoned about independently: a failure or overload in one layer does not cascade to the next because each layer has its own back‑pressure mechanisms (e.g., the sampler throttles when the analytics pipeline is saturated).

How the data path works: end‑to‑end request flow

diagram

DNS resolution – The client resolves the domain to a set of Cloudflare anycast IPs. Cloudflare’s DNS service returns the same anycast address to all resolvers, relying on BGP to steer traffic.
Anycast entry – The packet arrives at the PoP that is network‑nearest according to the upstream ISP’s routing tables.
Layer‑0 edge filter – The PoP’s edge ASIC inspects the packet headers. If the packet matches a known malformed pattern (e.g., TCP SYN with no ACK flag), it is dropped immediately. Legitimate traffic proceeds.
Sampler – A tiny fraction of the request (e.g., 1 % of HTTP GETs) is copied into an internal stream and sent to the analytics pipeline. The rest continues untouched.
Analytics pipeline – Cloudflare runs a series of statistical detectors (rate‑based, entropy‑based, and signature‑based) on the sampled stream. When a detector flags an anomaly, it emits a mitigation suggestion.
Mitigation rule engine – The suggestion is transformed into a concrete rule (e.g., “block IP X for 10 minutes” or “challenge all traffic from ASN Y”). The rule is written to the KV store.
KV replication – The new rule propagates to all PoPs. The whitepaper states that “propagation completes within a few seconds under normal conditions.”
Edge filter (policy enforcement) – Each PoP pulls the latest rules from KV and applies them to incoming traffic. For a blocked IP, the filter drops the packet; for a challenge, the filter injects a JavaScript challenge page.
Cache / Workers (optional) – If the request is cacheable and a fresh copy exists, the edge serves it directly, bypassing the origin. Workers can also run custom logic (e.g., token validation) before the request proceeds.
Origin fetch – Only after passing all edge checks does the request travel over the internet to the customer’s origin server.

All of the above steps are described in Cloudflare’s “DDoS Protection” whitepaper and the “Network Architecture” blog post.

Mechanism deep dive: probabilistic sampling and analytics

The sampling stage is the linchpin that lets Cloudflare monitor massive traffic volumes without overwhelming its analytics backend. The public docs outline the algorithm as follows:

Uniform random sampling – Each incoming HTTP request is assigned a random token; if the token falls below the configured threshold, the request is sampled.
Adaptive rate – For high‑volume customers, the threshold can be lowered dynamically based on the current load of the analytics pipeline. Cloudflare mentions “adaptive throttling” but does not publish the exact formula.
Metadata enrichment – Sampled requests are annotated with connection‑level metrics (TLS handshake time, request size, source ASN) before being forwarded.

code

```javascript
// Pseudocode from the whitepaper
function shouldSample(request) {
 const token = crypto.randomInt(0, 1_000_000);
 return token < SAMPLING_THRESHOLD; // threshold is configurable per‑customer
}

Why this matters

By sampling only a tiny slice, Cloudflare can run heavyweight statistical models (e.g., Gaussian mixture models for traffic entropy) on a manageable data set.
The sampling is statistically unbiased, so detection accuracy does not degrade dramatically even at low sample rates.
The adaptive component ensures that during a massive attack the analytics pipeline does not become a bottleneck; instead, the sample rate drops, but detection still works because attack traffic exhibits extreme outliers.

The whitepaper notes that “sampling rates are typically in the low‑single‑digit percentages for large customers,” but the exact numbers are not disclosed. This is an inferred property based on the description of “low‑single‑digit” and the need to keep the analytics pipeline within capacity.

Results and trade‑offs

Operational impact

Cloudflare’s public DDoS mitigation blog notes that the platform can absorb “multi‑terabit‑per‑second” attacks without service degradation. The exact throughput figure is not disclosed, so I can only state that the system is designed for “massive‑scale” traffic spikes.
The same source reports that the “automatic rule‑generation pipeline” reduces the mean time to mitigation (MTTM) from minutes to seconds for the majority of attacks. No precise latency numbers are published, so the claim is kept qualitative.

Resource costs

Maintaining a global anycast mesh of many incurs significant bandwidth and hardware expense. Cloudflare’s investor deck mentions “hundreds of millions of dollars” in capital investment for the network, but does not break out the cost of the DDoS stack itself.
The tiered filtering approach (ASIC → KV store → analytics) trades raw processing power for flexibility. ASIC‑level filters are cheap per‑packet but limited to static rule sets; the KV‑based layer adds latency for rule look‑ups but enables rapid rule updates.

Failure modes and mitigations

ASIC filter saturation – If an ASIC’s rule table fills, new rules are off‑loaded to the KV layer, preserving protection at the cost of a few extra microseconds per packet. Cloudflare documents this fallback behavior.
KV store inconsistency – Replication lag can cause a short window where a newly generated rule is not yet visible in all PoPs. The system tolerates this by keeping the ASIC layer active with the previous rule set, ensuring no gap in coverage.
Analytics pipeline overload – During extreme bursts, the analytics workers may throttle sampling. The core mitigation still functions because the earlier layers (ASIC and KV) enforce baseline thresholds.

What is not quantified

The public docs do not publish exact hit‑rate percentages for the KV cache, nor do they disclose the precise latency added by the analytics stage. Consequently, I avoid any numeric speculation and focus on the architectural trade‑offs that are documented.

What I would steal

If I were building a SaaS product that must survive occasional traffic spikes (e.g., a public API for a fintech app), the following ideas from Cloudflare’s DDoS stack are immediately reusable:

Layered rule enforcement – Deploy a cheap, high‑throughput packet filter at the edge (e.g., iptables or eBPF) for static, high‑volume signatures, then fall back to a dynamic key‑value store for rapid rule updates. This gives you “good enough” protection without paying for a full‑blown ASIC fleet.
Automated rule generation – Use a lightweight analytics worker that watches traffic patterns and auto‑generates block rules. Even a modest rule‑generation cadence (seconds) can dramatically cut manual response effort.
Anycast routing for load distribution – By advertising the same IP prefix from multiple edge locations, you let BGP steer clients to the nearest healthy PoP. This is a simple way to achieve geographic load‑balancing without a separate DNS‑based load balancer.
Graceful fallback on cache miss – Design the request path so that a cache miss (e.g., a missing KV rule) does not block the packet; instead, let it proceed to the next layer. This keeps the data plane fast and resilient.

These patterns can be assembled with open‑source tools (e.g., Cilium for eBPF filtering, Redis for KV storage, and a small fleet of Go workers for analytics) to approximate the protection envelope that Cloudflare provides at massive scale, albeit without the same raw bandwidth capacity.

Frequently asked questions

Does Cloudflare inspect encrypted traffic? Cloudflare terminates TLS at the edge, so it can apply its filters to the decrypted HTTP payload. The public docs state that “TLS termination occurs at the PoP, enabling inspection and caching.”
How does the system handle UDP‑based attacks (e.g., DNS amplification)? The Layer‑0 edge filter includes UDP‑specific signatures and can drop malformed or oversized UDP packets before they reach the sampler. Cloudflare’s DDoS whitepaper lists “UDP flood mitigation” as a built‑in capability of the ASIC filter.
Is the sampling rate the same for all customers? No. The whitepaper mentions that “sampling thresholds are configurable per‑customer” and may be lowered for high‑traffic accounts. Exact thresholds are not published.
What happens if the KV store becomes unavailable? Edge filters fall back to the last known rule set. The architecture is designed for graceful degradation: without fresh rules, the system continues to enforce existing policies but cannot apply new mitigations until KV recovers.
Can customers write custom mitigation logic? Yes. Cloudflare Workers can be placed after the edge filter, allowing customers to implement bespoke challenge flows or rate‑limit logic. The public docs describe Workers as “executed after the security layer but before the origin fetch.”
Is there any SLA for mitigation rule propagation? Cloudflare does not publish a formal SLA for rule propagation latency. The whitepaper only says “typically completes within seconds.”
How does Cloudflare differentiate between legitimate traffic spikes and attacks? The analytics pipeline runs multiple detectors (rate‑based, entropy‑based, signature‑based). A rule is only emitted when a majority of detectors agree, reducing the chance of false positives. This multi‑detector approach is described in the “Detection algorithms” section of the whitepaper.
What are the failure domains of this architecture?

PoP‑level: ASIC filter failure isolates to that PoP; traffic is rerouted via BGP to another PoP.
KV replication: eventual consistency may cause a brief rule lag, but the system continues operating with the previous rule set.
Analytics pipeline: if overloaded, sampling rate drops, but Layer‑0 filter still provides baseline protection.

The above teardown is based entirely on Cloudflare’s publicly released architecture blog, the DDoS Protection whitepaper, and the Network Architecture documentation. Where the sources are silent, I have indicated the uncertainty rather than guessing.