How Cloudflare Halved DNS Build Delay and Cut Memory Use by 85%

What prompted Cloudflare to overhaul its DNS propagation pipeline?

Cloudflare updated its DNS propagation pipeline to address scaling bottlenecks as zones grow past 20 million records. The Zone Builder now processes around 700 DNS record changes per second, nearly triple the volume from 2022, alongside numerous setting modifications.

While event volume increased, the real bottleneck was the type of work required and how it scaled with zone size. By introducing a targeted build planner and a unified scheduler, the company cut peak memory usage by 85% and halved the delay required to propagate changes to Quicksilver.

Why did full builds stop scaling effectively for large DNS zones?

The original architecture relied entirely on full builds, which required reading every DNS record in a zone, converting them into Quicksilver keys, and holding the entire dataset in memory. This approach became unfeasible for massive zones containing tens of millions of records.

Targeting zone settings proved much harder than tracking record changes because events from various Cloudflare products often lacked explicit reasons for modification. As discussed in el formulario S-1A de Anthropic, optimizing resource-heavy pipelines is critical for scaling large distributed systems effectively.

The team had to answer complex questions regarding which DNS names could change, how shared metadata was affected, and what previous states required removal from the distributed key-value store without breaking edge consistency.

How do targeted builds and the unified scheduler work?

The new targeted build planner evaluates events to select the smallest build type proven to be safe. It categorizes work into five distinct paths ranging from specific resource updates to metadata modifications and zone purges.

A unified scheduler combines multiple pending events for the same zone, preventing redundant operations and avoiding full-zone rebuilds above a fixed record-count threshold. Follow these steps to implement safe targeted updates in similar pipelines:

Verify the exact fields affected by incoming events before triggering updates.

Compare fresh database snapshots immediately prior to execution to catch asynchronous state changes.

How does the system handle shared metadata and multiple zone IDs?

Quicksilver stores individual record keys alongside a shared metadata directory that informs authoritative servers which internal zone IDs to use. During customer lifecycles, multiple zone objects can temporarily exist for a single public domain.

To prevent race conditions, the execution phase reads a fresh publication snapshot from database replicas. The DNS Kafka Aggregator delays events to account for normal replication lag, rejecting reads if the replica falls behind.

Frequently asked questions

Why did the original DNS Zone Builder stop scaling?

The primary cause was that full builds read, encoded, and compared every single record while holding the entire zone in memory, which failed to scale for zones with tens of millions of records.

How does the pipeline handle multiple zone IDs sharing the same domain name?

It solves this by using a priority policy to select a small, bounded set of zones to publish, writing the triggering zone's records before the shared metadata that refers to them.

What core components achieved the 85% memory reduction?

They built a targeted build planner that chooses the smallest safe build, a unified scheduler that combines work for the same zone, and skipped full builds above a record threshold.