Summary: Cloudflare’s Data team published a rundown of how they kept their telemetry pipeline inside existing hardware capacity despite exponential traffic growth. Between 2022 and fall 2026, schema splitting, compression swaps, replication changes, sampling, and aggregation deferred what they estimate as two and a half years of hardware expansion. For anyone operating data infrastructure at growing scale, the piece is a catalog of tradeoffs worth studying.
The core tension: exponential traffic, linear hardware
More than 20% of the web sits behind Cloudflare’s network, and their Data team’s pipeline moves logs, SQL API data, and observability signals from tens of thousands of servers into central data centers. By May of this year, the pipeline was delivering roughly two billion events per second.
Their framing is the useful part: traffic grows exponentially, hardware budgets grow linearly, so every year they need engineering wins that reset the clock. That’s a discipline any platform team can borrow — treat efficiency work as an annual ritual, not a one-off rescue.
Five changes, each buying back time
The sequence matters, because each fix targets a different layer:
- Breaking the monolithic schema (2022). One giant message carried every product’s fields, so every consumer ingested everything. Product-specific schemas duplicated some fields but cut backbone bandwidth by 35–40% — about a year of compressed traffic growth.
- LZ4 to zstd (2024). They had tried zstd earlier and backed off over CPU concerns. Careful metrics on a small rollout showed no meaningful CPU difference, so they went fleet-wide: nearly 40% less compressed traffic, roughly 10 months of growth deferred.
- Late replication (spring 2026). Double-writing every analytics event to two regions had doubled wide-area traffic. Borrowing Logpush’s shared-ingest model, they now send each event once and replicate downstream of sampling — a net reduction of 36 GB/s.
- Sampling at the source (summer 2026). Sampling earlier in Logfwdr, using a square-root-of-count sample per key, kept rare events intact while at least halving the wire volume for three top datasets — 25 GB/s total.
- Pipeline-wide aggregation (fall 2026). Moving rollups out of the ClickHouse inserters and into every pipeline stage dropped the HTTP dataset alone from over 9 GB/s to under 2 GB/s.
The transferable lesson: fix the cheapest waste first
Two patterns stand out for builders running their own pipelines. First, the biggest early win — the schema split — wasn’t clever, it was just deleting waste that a monolith had hidden. Before reaching for exotic techniques, check whether consumers are paying for data they never use.
Second, the replication change works because sampling and compression compound downstream. Sending raw, unsampled copies twice over the WAN is expensive; sending a single sampled, centrally compressed copy is cheap. When you architect for redundancy, think about where in the pipeline the copies get made — not just whether they exist.
There’s also a quiet lesson in the zstd story: their first experiment failed, and the second succeeded because they measured instead of assuming the CPU tradeoff still held. Fleet-wide changes deserve staged rollouts and tracked metrics, not vibes.
What this means for AI-era infrastructure
If you’re building on telemetry-heavy AI products, the same math applies. Agent logs, traces, and model observability generate event volumes that grow faster than your infra budget — a problem I’ve touched on before when looking at running log cleanup inside the export pipeline. Sampling and pre-aggregation at the producer, not the destination, are where the leverage is.
The limit to keep in mind: sampling answers questions approximately, and aggregation answers only the questions you picked in advance. Cloudflare ran both strategies in parallel precisely because neither covers every case. If your product needs arbitrary ad-hoc queries over raw events, you’ll pay for that fidelity somewhere — the trick is knowing which datasets actually need it.