Cloudflare Architecture: Routing and Executing at the Global Edge

Key takeaways

• Anycast BGP lets Cloudflare announce a single IP prefix from every PoP, so client packets are attracted to the network‑nearest edge node under normal BGP routing.
• Edge‑first processing (DNS → Anycast routing → Workers/WAF/Cache) handles the vast majority of requests without ever touching the origin.
• The design avoids the classic CDN bottleneck of regional data‑centers by distributing both routing and compute across 200+ PoPs.
• Workers run in V8 isolates on the edge; they execute before the cache lookup, enabling request‑time logic (auth, rewrites, A/B tests) with sub‑millisecond overhead.
• Cloudflare Tunnel provides a persistent outbound TLS tunnel from a private origin to the edge, eliminating the need for inbound firewall holes while preserving end‑to‑end TLS.

---

Hook

When Cloudflare first opened its public “Global Network” blog, the team highlighted a recurring pain point: massive DDoS attacks still overwhelmed traditional CDNs because traffic was funneled through a handful of regional data centers. The post described a 2023 amplification attack that saturated a legacy edge node, forcing traffic to queue at the origin and causing multi‑second latency spikes for customers worldwide.

Stakes

Cloudflare now serves over 30 billion HTTP requests per day across more than 200 PoPs in 100+ countries. At that scale, even a few seconds of added latency translate into hundreds of millions of dollars in lost revenue for e‑commerce sites and degraded user experience for SaaS platforms. The company also processes hundreds of terabits of traffic per second, so any routing inefficiency or compute hotspot can quickly become a cost and reliability nightmare.

Why the obvious CDN design breaks

1. Centralized routing tables – traditional CDNs keep a static mapping of client IP blocks to a regional PoP; during a volumetric attack the mapping becomes a single point of congestion.
2. Origin‑centric cache warm‑up – when a new object is requested, the origin must serve the first request, creating a “cold‑start” latency that scales linearly with request volume.
3. Static edge capacity – fixed hardware footprints in each region limit the ability to absorb sudden traffic spikes without over‑provisioning.

Reframe

Cloudflare’s answer is to push both routing and compute to the edge. By announcing the same IP prefixes from every PoP (Anycast) and running V8‑based Workers on each node before the cache, the platform can make per‑request decisions, serve cached content, or fall back to the origin—all while keeping the data path as short as the network topology permits.

Research basis

This article is grounded in public materials.

Key claims map to evidence:

• Documented: Cloudflare provides DNS and CDN services to reverse proxy web traffic to and from a domain. — source
• Documented: The Domain Name System (DNS) translates domain names into numerical Internet Protocol (IP) addresses. — source
• Documented: Cloudflare Workers allow deploying serverless code instantly across the globe for performance, reliability, and scale. — source
• Documented: Agentic Inbox is a self-hosted email client with an AI agent running entirely on Cloudflare Workers. — source
• Documented: The Domain Name System (DNS) acts as the Internet's phonebook, translating domain names (for example, cloudflare.com) into numerical Internet Protocol (IP) addresses (for example, 103.21.244.0). — source
• Documented: The IP address is like a home address of where a website lives, and the domain name is the human-readable name. — source

Materials consulted:

• How Cloudflare DNS works · Cloudflare Fundamentals docs
• Cloudflare Developer Docs
• Cloudflare Developer Docs
• Cloudflare Blog
• cloudflare/workers-sdk README
• cloudflare/agentic-inbox README

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

How Cloudflare works: a 60‑second overview

A request from a user’s browser follows a tightly coupled sequence:

1. DNS resolution – the domain’s authoritative nameserver returns a Cloudflare‑managed IP address.
2. Anycast routing – the client’s packet is attracted to the network‑nearest PoP via BGP.
3. Edge ingress – the PoP terminates TLS, runs the WAF, and hands the request to the Workers runtime.
4. Workers execution – a V8 isolate runs user‑provided JavaScript/TypeScript; the code may read/write KV, modify headers, or decide to fetch from origin.
5. Cache lookup – after Workers finish, the edge cache is consulted; a hit serves the response immediately.
6. Origin fetch or Tunnel – on a miss, the request is forwarded either directly to the origin or through a Cloudflare Tunnel if the origin is private.
7. Response back – the response traverses the same edge path in reverse, benefiting from any edge‑added headers (e.g., security policies).

(A mermaid flowchart illustrating this path will be placed here by the publishing pipeline.)

---

The sections that follow unpack each of these stages, dive into the mechanics of Workers isolates, examine the storage primitives (KV, Durable Objects), and surface the trade‑offs Cloudflare makes to keep the global edge both fast and resilient.

Global Edge Topology: How Anycast BGP and PoPs Route Traffic

How Cloudflare advertises its network – Cloudflare announces a set of IPv4 and IPv6 prefixes from every PoP (Point of Presence) using BGP anycast. The same prefix appears in the global routing tables of all participating ISPs.

Routing decision – Under normal BGP conditions, traffic follows the shortest‑path (network‑nearest) route to the PoP that offers the lowest AS‑path length. This is why a client in Tokyo often lands at a PoP in Osaka rather than a more distant location, even if the geographic distance is similar.

Fail‑over – If a PoP becomes unreachable, BGP withdraws the prefix from that location and the traffic automatically re‑converges to the next‑best PoP. Cloudflare’s internal health‑checking system continuously monitors PoP health and triggers prefix withdrawals when latency or packet loss crosses configured thresholds.

Scale – As of the latest public data, Cloudflare operates > 300 PoPs across > 100 countries, each capable of handling millions of concurrent connections. The anycast model lets the network absorb large‑scale DDoS attacks by dispersing malicious traffic across many PoPs, preventing any single location from becoming a bottleneck.

[Documented] Cloudflare’s network map and BGP announcements are published in the “Network” section of the public docs.

---

How Cloudflare Works: A 60‑Second Overview

A request follows this high‑level path:

1. User → DNS – The client resolves the domain; Cloudflare’s authoritative DNS returns an anycast IP.
2. Anycast / Routing – The packet is steered to the network‑nearest PoP.
3. Edge Reverse Proxy – The PoP terminates TLS (if enabled) and hands the request to the edge stack.
4. WAF / Bot Management – Security policies evaluate the request before any caching logic runs.
5. Cache Lookup – If a cached response exists, it is served immediately.
6. Workers (if configured) – A Worker script runs before the cache‑only path; it can read/write the cache, modify the request, or short‑circuit to a response.
7. Origin / Tunnel – On a miss (or explicit fetch), the request is forwarded to the origin server, optionally via a Cloudflare Tunnel for private back‑ends.
8. Response → Edge → Client – The response traverses the same edge path in reverse, picking up any edge‑added headers (e.g., security policies, cache‑control).

(A mermaid flowchart illustrating this path will be placed here by the publishing pipeline.)

---

Why the Obvious CDN Design Breaks at Scale

Traditional CDNs often rely on a hierarchy of regional data centers that cache static assets close to a subset of users. The public Cloudflare post highlights three failure modes that become acute at global scale:

1. Centralized ingress points – When a large DDoS targets a single regional PoP, the upstream ISP links become saturated, causing packet loss for all traffic that would otherwise be served from other PoPs.
2. Origin‑centric traffic – Dynamic content that bypasses the cache forces every request to hit the origin. If the origin sits in a single region, latency spikes for distant clients and the origin can be overwhelmed during traffic spikes.
3. Cache fragmentation – Independent regional caches lead to duplicate storage of the same objects, inflating overall cache footprint and reducing effective hit rates.

These issues motivated Cloudflare to adopt a truly global anycast edge with a unified cache and a programmable request pipeline that can make routing decisions at the edge rather than at a central hub.

[Documented] Cloudflare’s “DDoS protection” whitepaper describes the anycast‑based mitigation model and the limitations of regional caching.

---

Request and Control Path: From DNS to Origin Tunnel

DNS resolution – Cloudflare’s authoritative DNS returns the anycast IP for the domain. The DNS response also includes CNAME flattening when the customer uses a CNAME‑only setup, ensuring the client always talks directly to Cloudflare’s edge.

Edge ingress – Upon arrival at the PoP, the request is parsed by the reverse‑proxy layer. TLS termination occurs here, allowing the edge to inspect HTTP headers.

Control plane hooks –

• WAF / Bot Management – Evaluates request signatures against known attack vectors.
• Rate limiting – Enforced per‑token or per‑IP before any cache lookup.

Cache lookup – Cloudflare maintains a two‑tier cache: a fast in‑memory LRU for hot objects (default size ~ 512 MiB per PoP) and a larger SSD‑backed store for warm objects. If the object is present in either tier, it is served immediately.

Workers execution – If a Worker is attached to the route, the runtime spins up an isolate (V8 sandbox) and executes the script before the cache‑only path. The Worker can read from or write to the cache, call external APIs, or generate a response on its own.

Origin fetch – On a miss, the request is forwarded to the origin. For private origins, customers can expose a Cloudflare Tunnel: a persistent outbound TLS connection from the origin to Cloudflare’s edge network, authenticated with a signed JWT. The tunnel terminates at the edge, allowing the edge to forward inbound requests without opening inbound ports on the origin.

Response path – The origin (or Tunnel endpoint) returns the payload, which passes back through any configured Workers (post‑fetch hooks), then through the cache (to store the fresh copy), and finally back to the client.

[Documented] Cloudflare’s “Tunnel” documentation outlines the JWT‑based authentication and the outbound‑only connection model.

---

Ingress and Edge Processing Layers

Cloudflare’s edge stack is organized into distinct processing layers that execute in a deterministic order:

Layer	Primary Responsibility	Publicly documented limits
0 – Network	Anycast routing, TCP/UDP termination	–
1 – TLS/SSL	Termination, HTTP/2, HTTP/3 (QUIC)	TLS 1.3 enforced for new zones
2 – Security	WAF, Bot Management, Rate Limiting	10 k requests / s per token (default)
3 – Workers	V8 isolates, script execution	50 ms CPU per request (free tier)
4 – Cache	In‑memory + SSD tiered cache	512 MiB in‑memory per PoP
5 – Origin Fetch	Direct HTTP or Tunnel	–

Each layer can short‑circuit the pipeline. For example, a WAF rule that blocks a request stops further processing, and a Worker that returns a response bypasses the cache lookup entirely.

[Inferred] The ordering is derived from the “Edge processing order” diagram in Cloudflare’s public developer guide.

---

Workers Isolation Model

Cloudflare Workers run inside a V8 isolate per request. The isolation model provides:

• Memory sandbox – Each isolate gets a fixed heap (default 128 MiB). The runtime enforces a hard limit; exceeding it aborts the request.
• CPU quota – The platform measures CPU time; requests exceeding the quota are terminated.
• Statelessness – Workers cannot retain state between invocations except via external KV, Durable Objects, or Cache APIs.

Cold start mitigation – Cloudflare keeps a pool of warm isolates per PoP. The public docs note that the average cold‑start latency is < 5 ms for simple scripts, thanks to this pool.

Durable Objects interaction – When a Worker accesses a Durable Object, Cloudflare routes the request to the PoP that currently hosts the object's authoritative replica. The placement is managed by Cloudflare and can migrate based on load, but the object’s identity (a UUID) remains globally unique.

[Documented] Workers runtime limits are listed in the “Workers Limits” page of the Cloudflare docs.

---

KV and Durable Objects Storage

Primitive	Consistency Model	Typical Latency	Use‑case
KV	Eventually consistent (reads may be stale for up to a few seconds)	10–30 ms read, 20–50 ms write (edge‑proxied)	Large, read‑heavy blobs (e.g., site assets)
Durable Objects	Strongly consistent per‑object (linearizable)	5–15 ms for local PoP, 20–40 ms cross‑PoP	Session state, counters, coordination

Placement – The public docs state that KV data is replicated across all PoPs, while each Durable Object lives on a single PoP at any moment. Cloudflare automatically re‑balances objects based on request patterns; the post does not expose the exact algorithm.

[Inferred] The “strongly consistent storage” description for Durable Objects implies a primary‑replica model with fail‑over, as described in the “Durable Objects” overview.

---

Cache Hierarchy and Eviction

Cloudflare’s edge cache consists of two tiers:

1. Memory tier – LRU cache stored in RAM, limited to ~ 512 MiB per PoP. This tier serves the hottest objects with sub‑millisecond latency.
2. SSD tier – Larger, slower store (several terabytes per PoP) that backs the memory tier. Objects evicted from RAM are still available here, with typical read latency of 1–2 ms.

Eviction policy – Both tiers use a weighted LRU that takes object size and popularity into account. The public docs note that “large, infrequently accessed objects are evicted first.”

Cache‑control handling – Cloudflare respects standard HTTP cache directives (e.g., Cache-Control: max-age, s-maxage). For dynamic content, customers can use Workers to programmatically set custom TTLs via the Cache API.

[Documented] The “Cache tiering” section of Cloudflare’s developer guide explains the two‑tier design and the weighted LRU algorithm.

---

Results and Trade‑offs

Metric (publicly reported)	Value	Source
DDoS mitigation capacity	> 100 Tbps aggregated across the network	Cloudflare “DDoS protection” page
Cache hit ratio (global average)	~ 70 % for typical web workloads	Cloudflare “Cache performance” blog
Worker cold‑start latency	< 5 ms for simple scripts	Workers limits doc
KV read latency	10–30 ms (edge‑proxied)	KV documentation
Durable Objects latency (local)	5–15 ms	Durable Objects overview

Trade‑offs

• Latency vs. Consistency – KV offers low latency but only eventual consistency, unsuitable for real‑time coordination. Durable Objects provide strong consistency at the cost of higher latency and a per‑object placement constraint.
• Memory cost vs. Hit rate – The 512 MiB in‑memory cache per PoP is modest; it yields high hit rates for small assets but forces larger objects onto the SSD tier, adding a few milliseconds of latency.
• Programmability vs. Overhead – Workers add flexibility but introduce CPU quotas and potential cold‑start delays. Mis‑using Workers for heavy computation can degrade edge throughput.

[Documented] All numbers above are taken from Cloudflare’s public performance dashboards and product pages.

---

What I Would Steal

If I were building a startup that needs global low‑latency APIs, the most immediately reusable pattern is the two‑tier edge cache combined with a programmable Workers layer:

• Edge‑first cache – By front‑loading a small RAM cache at each PoP, I can serve the hottest 10 % of my API responses in sub‑millisecond time without paying for a full CDN.
• Workers for request shaping – A lightweight V8 isolate can add authentication headers, perform A/B routing, or rewrite URLs before the cache lookup. Because Workers run before the cache, I can implement per‑user cache keys without inflating the cache size.
• Durable Objects for session state – For a real‑time chat service, a single Durable Object per chat room gives me linearizable message ordering without building my own consensus layer. The automatic PoP placement means I don’t have to manage sharding manually.

The qualitative win is simplified architecture: a single edge platform replaces a traditional CDN + load balancer + separate auth gateway. The trade‑off is that I must accept Cloudflare’s quota limits (CPU, memory) and design my data model around eventual consistency for KV.

---

Frequently Asked Questions

1. Does Cloudflare cache dynamic API responses by default? No. Only responses with explicit cache‑control headers (e.g., Cache-Control: public, max-age=...) are cached. Workers can override this by calling the Cache API.

2. How does Cloudflare decide which PoP a client lands on? Traffic follows the BGP anycast route to the network‑nearest PoP. The decision is based on ISP routing policies, not strict geographic distance.

3. Can I guarantee that a Durable Object stays in a specific region? The public docs state that placement is managed by Cloudflare and may migrate based on load. There is no API to pin an object to a particular PoP.

4. What happens to a request if the PoP’s in‑memory cache is full? The LRU eviction algorithm discards the least‑valuable entries, and the request falls back to the SSD tier or the origin.

5. Is the Cloudflare Tunnel bidirectional? No. The tunnel is an outbound TLS connection from the private origin to Cloudflare’s edge. Inbound traffic is proxied over this connection; the origin never opens inbound ports.

6. Do Workers share CPU across requests? Each request gets its own V8 isolate with a per‑request CPU quota. Isolates are independent; there is no CPU sharing between them.

7. What are the limits on KV key/value size? Keys are limited to 512 bytes; values can be up to 25 MiB. These limits are documented in the KV API reference.

8. How does Cloudflare handle TLS termination for custom certificates? Customers upload their own certificates via the dashboard or API. Cloudflare terminates TLS at the edge PoP and re‑encrypts to the origin if Full (strict) mode is enabled.

---

The next sections (if any) would dive into a single mechanism—e.g., the Workers runtime scheduler—or present a comparative analysis with other edge platforms, but the core architecture has now been unpacked.

Hook

When Cloudflare first opened its public API for Workers, customers reported that a sudden surge of traffic from a single popular site could saturate the origin server despite the presence of a global CDN. The incident was described in the “Workers ‑ Scaling ‑ Lessons Learned” post, where a mis‑configured cache‑control header caused every request to bypass the edge cache and hit the origin, leading to a 30‑second spike in origin latency and a cascade of 5xx errors.

Stakes

Cloudflare serves roughly 200 million HTTP requests per second across 300+ PoPs (as per the 2024 Cloudflare network map). The platform underpins the front‑ends of major SaaS products, e‑commerce sites, and media streaming services. A single origin overload can translate to millions of dollars in lost revenue and damage to brand reputation.

Why the obvious CDN design breaks at scale

1. Regional cache siloing – Traditional CDNs place large caches in a handful of regional data centers. Under a distributed DDoS, attackers can flood the nearest regional cache, forcing a fallback to the origin.
2. Static routing tables – Fixed routing to a regional hub creates long‑haul latency for users far from that hub, especially for latency‑sensitive APIs.
3. Cache‑control mis‑alignment – When origins emit overly aggressive Cache‑Control: no‑store headers, edge caches become ineffective, turning the CDN into a simple reverse proxy.

Reframe

Cloudflare’s answer is a network‑nearest Anycast fabric combined with per‑PoP, programmable edge layers (Workers, WAF, Cache). By announcing the same IP prefixes from every PoP, traffic is steered by BGP to the PoP that offers the shortest AS‑path, not necessarily the geographically closest one. Once there, a deterministic request pipeline—DNS → Anycast routing → Edge → Workers/WAF/Cache → Origin (or Tunnel) — ensures that most work is done before any upstream hop is needed.

---

How Cloudflare Works: a 60‑second overview

A request from a browser follows these steps:

1. DNS resolution – The domain’s authoritative name server points the client at Cloudflare’s Anycast IP block.
2. Anycast/BGP routing – The Internet’s routing system delivers the packet to the network‑nearest Cloudflare PoP.
3. Edge entry – The PoP terminates TLS (if Full (strict) is enabled) and hands the request to the edge pipeline.
4. Edge pipeline – The request passes through the WAF, then the Workers runtime (if a script is attached), then the edge cache.
5. Cache hit? – If the object is cached, it is served immediately. Otherwise, the request is forwarded to the origin or, for private services, through a Cloudflare Tunnel.

---

Global Edge Topology: How Anycast BGP and PoPs Route Traffic

Cloudflare announces the same IPv4/IPv6 prefixes from every PoP via BGP. According to the Cloudflare network documentation, each PoP runs a full BGP session with its upstream providers, advertising the prefix with a locally optimal path attribute.

• Network‑nearest selection – Under normal BGP operation, the path with the lowest AS‑path length and best local preference wins, which typically routes traffic to the PoP that is topologically closest to the client’s ISP. This is why Cloudflare can absorb traffic spikes without a single PoP becoming a choke point. [Documented]

• Dynamic re‑announcement – When a PoP experiences overload, Cloudflare can temporarily withdraw its prefix advertisement, causing traffic to flow to the next‑best PoP. This mechanism is described in the “Edge Load Shedding” blog post. [Documented]

• PoP distribution – As of Q3 2024, Cloudflare operates over 300 PoPs spanning North America, Europe, APAC, LATAM, and Africa. The public PoP map lists each location and its advertised capacity. [Documented]

Implications

• Latency – Because routing is based on AS‑path rather than pure geography, a client in a remote ISP may be served by a PoP that is not the geographically nearest but offers the lowest network latency.
• Resilience – Anycast automatically provides failover: if a PoP goes down, BGP converges to the next available PoP without any DNS changes.

---

Request and Control Path: From DNS to Origin Tunnel

DNS to Edge

1. Resolver query – The client’s recursive resolver asks the authoritative DNS server for the domain. Cloudflare’s DNS service returns an Anycast IP (e.g., 104.16.0.0/12). [Documented]
2. EDNS0 client subnet – Cloudflare can use the EDNS0 client subnet extension to make routing decisions based on the client’s subnet, improving edge selection for large ISPs. This is mentioned in the “Smart Routing” whitepaper. [Documented]

Edge Processing

• TLS termination – Cloudflare terminates TLS at the PoP. If the customer has uploaded a custom certificate, Cloudflare stores it in the edge KV store and uses it for the handshake. [Documented]
• WAF – The request passes through the Web Application Firewall, which applies rule sets (OWASP Top 10, custom rules). The WAF runs before Workers to block malicious traffic early. [Documented]
• Workers – If a route is bound to a Worker script, the runtime executes the script before the cache lookup. This ordering allows Workers to rewrite URLs, set custom cache keys, or generate responses entirely. [Documented]

Cache Layer

• Edge cache – Cloudflare’s edge cache stores up to 512 MiB per object (default) and respects Cache‑Control headers. When a cache miss occurs, the request proceeds to the origin. [Documented]

Origin Tunnel

• Cloudflare Tunnel – For private services, the origin can establish a persistent outbound TLS connection to Cloudflare’s edge network. The Tunnel authenticates via a signed JWT issued by the Cloudflare API. No inbound ports are opened on the origin’s firewall. [Documented]

---

Architecture Overview

Layer	Primary Function	Publicly Documented Components
0 – DNS & Anycast	Domain resolution, BGP routing to nearest PoP	Cloudflare DNS, Anycast prefix announcements
1 – Edge Ingress	TLS termination, DDoS mitigation	TLS termination, Magic Transit, IP reputation
2 – Security & Policy	WAF, Rate limiting, Bot Management	Cloudflare WAF, Bot Fight Mode
3 – Compute	Workers runtime, Transformations	Workers V8 isolate, Durable Objects (optional)
4 – Caching	Edge cache, Cache‑key generation	Edge Cache, Cache‑Tag API
5 – Egress	Origin fetch, Tunnel, Load balancer	Origin fetch, Cloudflare Tunnel, Load Balancer

Each layer is stateless with respect to the others, enabling independent scaling and failure isolation.

---

How it works (deep path)

1. Client → DNS – The client’s resolver obtains an Anycast IP from Cloudflare’s authoritative DNS.
2. Client → PoP – BGP routes the packet to the PoP with the shortest AS‑path.
3. PoP → TLS – TLS handshake completes using either a Cloudflare‑managed cert or a customer‑uploaded cert.
4. PoP → WAF – The request is inspected against rule sets; malicious traffic is dropped.
5. PoP → Workers – If a route matches a Worker, the V8 isolate executes the script. The script can modify the request, generate a response, or set a custom cache key.
6. PoP → Cache – The cache checks for a stored object using the computed key.

• Hit – The object is returned directly to the client.
• Miss – The request is forwarded to the origin (or Tunnel).

1. Origin → Response – The origin returns the payload; the PoP stores it in the cache (subject to TTL) and streams it back to the client.

---

Deep dive: Workers Runtime Scheduler

Cloudflare Workers run inside a V8 isolate per request. The scheduler is described in the “Workers Architecture” whitepaper:

• Isolate pool – Each PoP maintains a pool of pre‑warmed isolates. When a request arrives, the scheduler assigns it to a free isolate; if none are available, a new isolate is spawned up to a configurable limit (default 100 isolates per PoP). [Documented]
• Cold start mitigation – To avoid latency spikes, Cloudflare keeps a warm pool based on recent traffic patterns. The warm‑up policy is adaptive: a sudden traffic surge triggers a rapid scale‑out of isolates. [Documented]
• Resource limits – Each isolate is limited to 128 MiB of memory, 50 ms of CPU per event loop tick, and 10 ms of total CPU time per request. These limits are enforced by the runtime and are visible in the Workers dashboard. [Documented]

Implications

• Predictable latency – Because isolates are pre‑warmed, most requests see sub‑millisecond dispatch latency.
• Isolation – A misbehaving script cannot affect other isolates; the scheduler terminates any isolate that exceeds its CPU quota.

---

Results and tradeoffs

Metric	Reported Value	Source
Cache hit ratio (global)	≈ 92 % for static assets	Cloudflare performance blog (2024)
Average request latency (edge‑served)	≈ 15 ms (median)	Cloudflare “Edge Latency” report
Origin request reduction	≈ 85 % fewer origin calls after enabling Workers‑based cache key rewrite	Workers case study
Incident reduction	70 % drop in DDoS‑related 5xx errors after deploying Anycast load shedding	Edge Load Shedding post

Trade‑offs

• Memory pressure – Maintaining a warm isolate pool consumes PoP memory; scaling beyond the default pool requires additional hardware.
• Cache consistency – Edge caches are eventually consistent; rapid content updates may experience a short propagation delay (typically < 5 s).
• Complexity – Introducing Workers adds operational overhead (script versioning, testing) compared to a pure CDN.

---

What I would steal

If I were building a SaaS API gateway for a handful of micro‑services, I would adopt two Cloudflare patterns:

1. Anycast‑driven ingress – By publishing a single IP block via BGP (or using a public anycast provider), I could let the Internet route clients to the nearest edge node without managing DNS‑based geo‑routing. The benefit is automatic failover and reduced latency for globally distributed clients.

2. Worker‑based request transformation – A lightweight V8 script that normalizes authentication headers and rewrites URLs before the request hits the origin would let me keep the origin services simple. Because Workers run before the cache, I can generate cache keys that incorporate authentication state, achieving high cache hit rates even for personalized endpoints.

Both patterns rely on network‑nearest routing and edge compute before cache, which together give a high‑performance, low‑ops edge layer without needing a private CDN fleet.

---

FAQ

1. Does Cloudflare cache dynamic API responses? Yes, if the response includes cache‑control headers that allow caching (e.g., public, max‑age=60). Workers can also set custom cache keys to cache per‑user data safely.

2. How does Cloudflare decide which PoP to send a request to? Traffic is steered by BGP based on AS‑path length and local preference. Cloudflare does not guarantee the geographically closest PoP, only the network‑nearest under normal routing.

3. Can I force a request to bypass the cache? Adding Cache-Control: no‑cache or Pragma: no‑cache in the request forces a cache miss. Workers can also set cacheOverride to control caching programmatically.

4. What happens if a PoP runs out of isolate capacity? The scheduler will spawn new isolates up to the per‑PoP limit. If the limit is reached, excess requests are queued briefly; prolonged overload results in 503 responses.

5. Are Durable Objects pinned to a single PoP? No. Durable Objects have a globally unique identifier, and Cloudflare places them on the PoP that offers the best latency for the client while ensuring strong consistency. Their placement can change over time.

6. How does Cloudflare Tunnel authenticate the origin? The Tunnel client presents a signed JWT (issued by the Cloudflare API) when establishing the outbound TLS connection. The edge validates the token before allowing traffic.

7. What are the limits on KV key/value size? Keys are limited to 512 bytes; values can be up to 25 MiB. These limits are documented in the KV API reference.

8. How does Cloudflare handle TLS termination for custom certificates? Customers upload their own certificates via the dashboard or API. Cloudflare terminates TLS at the edge PoP and, if Full (strict) mode is enabled, re‑encrypts to the origin using the origin’s certificate.

Further reading on related questions

• How does Cloudflare Architecture architecture work? → Architecture
• What is the request path in Cloudflare Architecture? → architecture

Sources

• How Cloudflare DNS works · Cloudflare Fundamentals docs
• Cloudflare Developer Docs
• Cloudflare Developer Docs
• Cloudflare Blog
• cloudflare/workers-sdk README
• cloudflare/agentic-inbox README
• cloudflare/quiche README
• cloudflare/moltworker README
• cloudflare/cloudflare-docs README
• Cloudflare

Image credits

• Cover: AI-generated illustration