How Cloudflare’s edge network handles over 60 million RPS

Building a network capable of handling peak traffic of over 60 millionhttps://blog.cloudflare.com/analysis-of-the-epyc-145-performance-gain-in-cloudflare-gen-12-servers/ legitimate requests per second, while also defending against record-breaking attacks as large as 71 millionhttps://blog.cloudflare.com/cloudflare-mitigates-record-breaking-71-million-request-per-second-ddos-attack/ requests per second, requires distributed intelligence and real-time defense. As a company that operates one of the world’s largest networks for content delivery, security, and edge computing, Cloudflare relies on a distributed-first modelAn approach that decentralizes compute, security, and control across global edge nodes rather than relying on a central core, enabling faster response, higher resilience, and local autonomy. in which every edge node can cache, compute, and defend traffic autonomously.

This newsletter examines the architectural design, software stack, and operational principles that enable this global infrastructure to be possible. It also identifies lessons that engineers and system designers can apply to their own large-scale systems. Here's what else we'll cover:

• The logic behind the global edge server network

• How Anycast routing provides speed and resilience

• Strategies for absorbing massive DDoS attacks

• Principles for building and scaling large-scale systems

Let's get started.

Cloudflare’s network#

Cloudflare’s architecture follows the principle that each data center is capable of running every core service on its servers, enabling uniform functionality across the network. This model extends beyond content delivery to form a unified platform where security, performance, and compute operate at the edge, close to end users. With a network now handling over 60 million requests per second, this design has demonstrated its ability to scale under sustained global demand.

For system designers, this model illustrates how distributed architectures minimize latency, improve resilience, and filter malicious traffic before it reaches origin servers. Moving compute and security away from centralized cores ensures that a server in Tokyo handles a request from a user in Tokyo, rather than one in Virginia.