Cloudflare Data Team Defers 2.5 Years of Hardware Expansion via Pipeline Optimizations

Cloudflare’s Data team has implemented a series of architectural changes to its data pipeline, effectively deferring two and a half years of hardware expansion. By addressing exponential traffic growth against linear hardware capacity, the team reduced compressed backbone traffic by approximately 70 GB/s between spring and fall 2026. These optimizations support a network handling over 20% of the web and delivering roughly two billion events per second.

Breaking the Monolith and Improving Compression

In 2022, the team dismantled a single monolithic schema that forced internal consumers to ingest all product fields. Replacing this with product-specific schemas reduced backbone bandwidth usage by 35-40%. In 2024, they switched the compression algorithm from LZ4 to zstd. While initially concerned about CPU overhead, gradual rollout showed negligible impact, resulting in a nearly 40% reduction in compressed traffic throughput and allowing the system to support 1.5x more traffic with the same infrastructure.

Load Balancing and Late Replication

To handle disaster resilience without doubling wide-area transit traffic, the team moved away from double-writing every event to multiple regions. Instead, they adopted a shared ingest pool model where Logfwdr sends each event exactly once to an available centralized receiver. Replication now happens later in the pipeline via Buftee, the distributed buffering layer. This shift eliminated approximately 43 GB/s of compressed transit traffic while adding only ~7 GB/s of cross-data-center replication, for a net reduction of 36 GB/s.

Early Sampling and Aggregation

The team expanded sampling to occur directly in Logfwdr rather than just at centralized receivers. Using a square-root sampling algorithm, they reduced data volume while maintaining representative samples. For top datasets, this halved the compressed data sent on the wire, saving 25 GB/s (over 2 PB/day). Additionally, they decentralized aggregation, moving calculations like unique IP counts and request sums earlier in the pipeline. For the HTTP dataset, this reduced compressed traffic from 9+ GB/s to <2 GB/s, an 80% reduction.

Resource Impact

These changes have had immediate effects on resource usage. For the Ready-Analytics dataset, load balancing and sampling reduced throughput from ~26 GB/s to ~8 GB/s. Without these interventions, traffic would have breached 60 GB/s by September. The optimizations also freed up ~750 CPUs and 3.5 TiB of memory in the Ready-Analytics receivers alone. Collectively, these steps have halved the projected data processing load for the next five years.