Cloudflare has 300+ Points of Presence (PoPs) globally. When you make a request to a Cloudflare-protected site, you don’t connect to a server in a specific city — you connect to the nearest Cloudflare PoP, wherever that is. This works via anycast: multiple servers worldwide share the same IP address, and BGP routing delivers your packets to the geographically closest one. PoP placement and anycast are the foundation of how CDNs achieve global low latency.

Anycast vs Unicast#

Unicast: one IP address belongs to one server. DNS-based routing directs clients to different servers by returning different IP addresses. Round-trip adds DNS lookup time; failover requires DNS propagation.

Anycast: the same IP address is announced by dozens of servers via BGP. Routers on the internet path packets to the “closest” announcement based on BGP path metrics. No DNS lookup needed per request — the IP itself routes to the nearest node. When a PoP goes down, BGP withdraws its announcement within seconds and traffic automatically routes to the next nearest PoP.

graph TD A[Client in Tokyo: SYN to 104.16.0.1] --> B[BGP: nearest announcement wins] B --> C[Tokyo PoP announces 104.16.0.1 via AS13335] B --> D[Frankfurt PoP announces 104.16.0.1 via AS13335] B --> E[São Paulo PoP announces 104.16.0.1 via AS13335] C --> F[Tokyo PoP wins: fewest hops from Tokyo client] F --> G[Connection lands at Tokyo PoP: 2ms RTT] style A fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style B fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style C fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style D fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style E fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style F fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style G fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff

PoP Placement Strategy#

Where to put PoPs is an optimization problem: minimize latency for the most users per dollar of infrastructure cost.

Population density: place PoPs in major cities first. A PoP in Mumbai serves 400 million internet users. A PoP in a smaller city serves far fewer.

Internet exchange points (IXPs): locations where ISPs exchange traffic directly. A PoP at an IXP can peer with dozens of ISPs simultaneously, reducing latency and transit cost. Major IXPs: Equinix in Frankfurt, Amsterdam (AMS-IX), Singapore (SGIX), Chicago (ChIX).

Latency budget: users tolerate under 50ms round-trip for interactive applications. A PoP must be within ~5,000km to serve users at under 50ms (speed of light in fiber: ~200,000 km/s). Coverage maps guide placement decisions.

PoP Sizing#

PoPs are not equal in size. A PoP in Frankfurt handles massive traffic (serves all of Western Europe). A PoP in Nairobi handles less. PoPs are sized by the traffic they’re expected to handle: number of servers, network capacity, cache storage. Small PoPs (edge nodes) handle termination and cache hits; large PoPs (core nodes) also handle cache misses and origin fetches.

At Oracle#

Oracle Cloud Infrastructure has regional data centers, not a global CDN PoP network. For a customer who needed low-latency delivery in Southeast Asia, we combined OCI regional endpoints in Singapore with Cloudflare in front for PoP coverage across Thailand, Vietnam, and Malaysia. The origin was OCI Singapore; Cloudflare’s PoPs in Bangkok, Ho Chi Minh, and Kuala Lumpur served cached responses with sub-20ms latency to end users. Origin latency (50-80ms) was only seen on cache misses.

What I’m Learning#

Anycast eliminates the DNS layer from latency-sensitive routing decisions: traffic finds the nearest PoP through BGP convergence rather than DNS lookup. PoP placement is about maximizing population coverage per infrastructure dollar, anchored to IXP locations where peering relationships are densest.

Have you designed or evaluated CDN PoP placement strategies, and what metric drove placement decisions?