In May 2026, Cloudflare’s data pipeline was delivering roughly 2 billion events per second — customer traffic plus internal data — from a network that sits in front of more than 20% of the web and spans tens of thousands of servers. Traffic grows exponentially; hardware purchases grow linearly. By the company’s own accounting, five years of changes to the pipeline have deferred about two and a half years of hardware expansion. The fixes, detailed by Cloudflare’s data team on its engineering blog, are a case study in where backbone bandwidth actually goes: schemas, compression, replication and sampling, in that order of intervention.
The pipeline’s shape, in one line: Logfwdr, an internal collection service running on thousands of distributed servers, feeds centralized receivers, which push onto Buftee, a distributed buffering layer; consumers pull from Buftee into destinations such as ClickHouse, which the company says it relies on heavily.
2022: one schema becomes many
Until 2022, every product’s fields rode on a single monolithic stream. A consumer that wanted Security metadata also received HTTP and CDN fields, and had to demux or discard the rest via filters. The team’s hypothesis was that no internal team needed 100% of the schema. Splitting the firehose into per-product schemas meant deliberately duplicating some fields into multiple messages — and it still cut backbone bandwidth usage by 35–40%, which the company equates to roughly a year of compressed traffic growth deferred. The lesson generalizes: at scale, bytes you never serialize are the cheapest bytes.
2024: zstd in place of LZ4
By 2024 the team was fighting daily network congestion. It swapped the compression algorithm from LZ4 to zstd, having previously avoided zstd over CPU concerns from earlier experiments. A staged rollout — a few servers, then the full fleet — showed no noticeable CPU impact either time. The result was nearly a 40% reduction in compressed traffic throughput while uncompressed bytes kept growing at the same rate: more than 1.5× the traffic through the same-size pipe, or an estimated 10 months of growth-equivalent headroom. CPU turned out to be cheaper than bandwidth, but the team only committed after measuring that it stayed cheap.
Spring 2026: send each event once, replicate at the last moment
Disaster resilience against regional failures had worked by double-writing: Logfwdr transmitted two full copies of every non-regional analytics event, one to each centralized region, and each region processed its complete copy into ClickHouse and applied its own sampling. (Data under Customer Metadata Boundaries stays strictly in its designated region.) That was manageable while a handful of streams had secondary regions. Once disaster resilience expanded to almost all analytics streams, Logfwdr’s wide-area traffic doubled — unsustainable against exponential growth.
The Logpush product had already solved a similar problem: because delivery is stateless, Logfwdr treats the centralized data centers as one shared pool of receivers and sends each message exactly once, failing over automatically when a machine or facility is unreachable. Analytics was harder, because ClickHouse clusters in both regions must each hold a full copy of non-regional data for instant, independent query failover. The fix decoupled transit from redundancy in three parts. First, a shared ingest pool: Logfwdr dispatches each event exactly once across the WAN to whichever receiver is available. Second, replication happens as late as possible: data lands in Buftee and remote inserters stream the cross-data-center copy downstream. Third, failure handling: if a region goes down, all non-regional traffic reroutes to the survivor, and if the inter-center link blips, each cluster keeps ingesting its local share without backpressure while remote inserters catch up from Buftee’s retention buffer.
For the migrated datasets, the cutover eliminated approximately 43 GB/s of compressed WAN transit and added only about 7 GB/s of cross-data-center replication — a net reduction of 36 GB/s, roughly 288 Gbps of wide-area traffic. Two mechanisms explain why the replacement copy is about six times cheaper than the one it replaces. Replication now happens downstream of sampling: the old model shipped two copies of raw, unsampled events, while the new model samples at the receiver first and replicates only the compacted stream. And compression works better after centralization: data at the source is fragmented across thousands of servers into small batches, while centralized streams get aggregated and partitioned into uniform batches over wider time windows, which compression algorithms can squeeze much harder. The rollout began with two datasets — HTTP analytics and Ready-Analytics, the in-house one-click analytics product — and migration has continued since spring.
Summer 2026: sample before you ship
The fourth lever moved sampling from the centralized receivers back into Logfwdr itself, so less data crosses the WAN in the first place. Each dataset has a key chosen by its producer team. Records per key are shuffled to remove ordering bias, and for each group the sample size is set to the square root of the total record count — a scheme that stays representative through both rounds of sampling. Estimates are rescaled against the sample rate: sample 10 of 100 records and the rate is 10/100, so the unbiased count estimate is 10×10 = 100. Rare events are preserved while high-volume traffic is downsampled.
Validation compared the number of rows actually written to ClickHouse against the estimated sums, across many keys spanning least-seen to most-seen and across a range of traffic footprints. The post closes the sequence with a fifth change listed for fall 2026: pushing aggregations into the pipeline, details not yet given.
Two caveats apply to the whole ledger. The 36 GB/s figure comes without a denominator — the post never states total WAN throughput, so the relative saving is unknown. And “two and a half years of hardware deferred” is the company’s own growth-equivalent estimate, not a measured budget line. The next numbers worth watching are whatever the fall aggregation rollout publishes, against a baseline that was already 2 billion events a second this spring.