Cloudflare: cinque interventi in cinque anni per rallentare la crescita dell'hardware dati

Cloudflare ha pubblicato il 13 ottobre 2026 sul suo blog tecnico il dettaglio di cinque interventi, fatti tra il 2022 e l'autunno 2026, per contenere la crescita dell'hardware dietro la propria pipeline di dati. Il tema riguarda chiunque usi Cloudflare Logs, la SQL API o i prodotti di analytics: è l'infrastruttura che raccoglie e smista i log da cui quei prodotti leggono.

Più del 20% del web sta dietro la rete di Cloudflare, e il team Data possiede la pipeline che porta quei dati dalla rete globale ai data center centrali, su una rete distribuita che copre decine di migliaia di server. A maggio 2026 la pipeline erogava circa due miliardi di eventi al secondo, inclusi traffico dei clienti e dati interni. Per fare un confronto: a dicembre 2024 Cloudflare dichiarava che la stessa pipeline ingeriva circa 706 milioni di eventi al secondo, secondo un post precedente dello stesso blog. In meno di due anni il volume è quasi triplicato.

Cinque interventi, cinque anni

Anno	Intervento	Effetto dichiarato da Cloudflare
2022	Smontaggio dello schema monolitico in schemi per prodotto	-35/40% di banda sul backbone
2024	Cambio compressione da LZ4 a zstd	-40% traffico compresso, stesso tubo regge 1,5x il traffico
Primavera 2026	Nuova architettura di replica (load balancing)	eliminati circa 43 GB/s di traffico di transito compresso, con l'aggiunta di soli ~7 GB/s di replica cross-data center
Estate 2026	Sampling spostato a monte, in Logfwdr	-25 GB/s sui tre dataset principali, oltre 2 PB/giorno
Autunno 2026	Aggregazioni inserite in pipeline	sul dataset HTTP, calo da oltre 9 GB/s a meno di 2 GB/s, circa -80% sul filo

Per il load balancing, il primo taglio è arrivato sul dataset HTTP analytics con una riduzione di circa 20 GB/s (oltre il 50%), mentre il dataset Ready-Analytics è sceso del 43%, da circa 28 a 16 GB/s.

Perché interessa a chi gestisce log propri

Le tecniche descritte non sono esclusive di Cloudflare: schema per prodotto invece di un unico schema monolitico, compressione zstd al posto di LZ4, sampling applicato il più a monte possibile e aggregazioni calcolate in pipeline invece che a query-time sono pattern riusabili su qualunque stack di log basato su buffer e ClickHouse (o simili). Nella pipeline di Cloudflare i dati arrivano dai receiver centralizzati, passano sul sistema di buffering Buftee e da lì vengono distribuiti alle destinazioni finali come ClickHouse. Chi gestisce una pipeline di log con un volume anche solo di qualche ordine di grandezza inferiore può applicare la stessa logica per rimandare un upgrade di banda o di storage.