Cloudflare recorta 70 GB/s de tráfico con 3 cambios

Cloudflare mueve 2.000 millones de eventos por segundo: así recortó 70 GB/s

Cloudflare eliminó cerca de 70 GB/s de tráfico comprimido de su backbone de datos entre la primavera y el otoño de 2026, según detalló su equipo de Data en el blog de ingeniería de la compañía. Para dimensionarlo: en mayo de este año la red procesaba alrededor de 2.000 millones de eventos por segundo, y más del 20% de la web pasa por su infraestructura.

El problema que describe el equipo es el mismo que enfrenta cualquier startup que crece: el tráfico sube de forma exponencial y el hardware, de forma lineal. La diferencia es que Cloudflare lleva cinco años peleando esa batalla y documentó exactamente cómo la ganó. Ese playbook es lo valioso.

¿Cómo procesa Cloudflare 2.000 millones de eventos por segundo?

El pipeline arranca en Logfwdr, un servicio interno que recolecta datos de fuentes muy distribuidas (Workers, por ejemplo). De ahí pasan a receptores centralizados, luego a un sistema de buffering llamado Buftee, y finalmente los consumidores los distribuyen a destinos como ClickHouse, la base de datos analítica en la que Cloudflare se apoya fuertemente.

Cada eslabón de esa cadena es una oportunidad para procesar menos datos sin perder calidad. Eso es, en una frase, toda la estrategia.

Los cuatro cambios que liberaron 70 GB/s

El equipo desarmó el problema en cuatro intervenciones, cada una con su propio ahorro medido.

• 2022 — Separar el esquema monolítico. Antes había un único stream con los campos de todos los productos, y cada consumidor interno tenía que ingerir todo y filtrar lo que no le servía. Al crear esquemas por producto, el uso de ancho de banda del backbone cayó 35-40%, equivalente a eliminar aproximadamente un año de crecimiento de tráfico comprimido.
• 2024 — Cambiar la compresión. Migraron de LZ4 a zstd y lograron casi 40% menos de throughput comprimido. El resultado práctico: la misma tubería soportaba más de 1,5x el tráfico. Cloudflare ya había probado zstd antes y había descartado la idea por el mayor uso de CPU, así que esta vez midieron con cuidado antes de desplegar a toda la flota.
• Primavera 2026 — Replicación diferida. El sistema duplicaba cada evento para tener redundancia entre regiones. Al pasar a un modelo de ingesta compartida y replicar lo más tarde posible en el pipeline, eliminaron ~43 GB/s de tránsito comprimido y sumaron solo ~7 GB/s de replicación entre centros de datos: una reducción neta de 36 GB/s. El truco fue replicar después del sampling y aprovechar que los datos centralizados se comprimen mucho mejor que los fragmentos que salen de miles de servidores.
• Verano 2026 — Sampling desde el origen. Movieron el muestreo a Logfwdr. En los tres datasets principales, cada uno al menos duplicó la reducción: 25 GB/s en total, más de 2 PB por día. El detalle técnico importa: la muestra se calcula con la raíz cuadrada del total de registros, así que las claves con más volumen se atenúan y las raras conservan su detalle.
• Otoño 2026 — Agregación distribuida. En lugar de agregar solo al final, ahora agregan en cada paso. En el dataset HTTP, el tráfico comprimido pasó de 9+ GB/s a menos de 2 GB/s, una reducción cercana al 80% en el cable.

El crecimiento exponencial se come las mejoras

Hay una lección incómoda en los propios números de Cloudflare. En Ready-Analytics, su producto de analítica en un clic, el load balancing bajó el tráfico de ~26 GB/s a ~13 GB/s a mediados de mayo. Dos meses después ya había vuelto a ~20 GB/s por crecimiento orgánico: la mitad del ahorro, borrada.

El sampling volvió a bajar el consumo a un dígito, ~8 GB/s. Sin ambas intervenciones, según la compañía, ese solo dataset habría superado los 60 GB/s en septiembre. El ahorro no es un logro permanente: es una carrera que se vuelve a correr cada trimestre.

El impacto operativo también fue concreto. Solo en los receptores de Ready-Analytics, el load balancing y el sampling recortaron ~50% del uso de CPU y memoria, liberando ~750 CPUs y 3,5 TiB de memoria.

¿Qué significa esto para tu startup?

No necesitas 2.000 millones de eventos por segundo para que esto te sirva. El patrón se repite en cualquier empresa que paga por transferencia de datos: los cargos de egress son uno de los costos que más rápido se descontrolan, precisamente porque casi nadie los mira hasta que llega la factura, como recuerda TechTarget en su guía sobre cargos de transferencia en la nube.

Y el contexto de mercado empuja en la misma dirección. UBS proyecta que el capex de los grandes hyperscalers podría llegar a unos US$4,1 billones entre 2026 y 2028, y estima que Amazon, Alphabet y Microsoft gastarán en 2026 cerca del 102% de sus ingresos de nube en capital expenditures, según reportó 247wallst. Cuando el hardware se vuelve el costo dominante, exprimir cada byte deja de ser una optimización de ingeniería y pasa a ser una decisión de negocio.

Tres acciones que puedes aplicar esta semana:

• Mide antes de optimizar. Cloudflare probó zstd, vio más CPU y lo descartó; años después volvió con métricas. Antes de cambiar un algoritmo de compresión o un formato de mensaje, instrumenta el costo real (CPU, ancho de banda, almacenamiento) y decide con datos, no con intuición.
• Mueve el filtrado y el muestreo lo más cerca del origen posible. Cada byte que descartas en el productor es un byte que no viaja, no se comprime, no se almacena y no se paga. Es el cambio con mejor relación esfuerzo/ahorro de todo el artículo.
• Separa la lógica de negocio de la arquitectura de datos. El mayor salto de Cloudflare en 2022 no fue técnico sino de diseño: dejar de mandar todo a todos. Si tu equipo consume un stream gigante y filtra en el destino, tienes ahí un 35-40% esperando.

Un dato de contexto sobre Cloudflare

Vale aclarar el lugar que ocupa la compañía en el mapa. En el Magic Quadrant de Gartner para infraestructura de nube de IA de 2026, Cloudflare aparece listada como Niche Player, enfocada en inferencia en el edge y sin soporte para entrenamiento de modelos a gran escala, según el análisis de CRN. Su fuerte es otro: un modelo de precios por uso real y R2, su almacenamiento de objetos que elimina los cargos de egress, el mismo dolor que este artículo de ingeniería intenta resolver puertas adentro.

La conclusión que deja el post es la más útil para un founder: las optimizaciones estructurales y algorítmicas no son un proyecto que se termina, son una disciplina que se mantiene. Cloudflare calcula que los cambios de este año por sí solos equivalen a haber recortado a la mitad el volumen de datos que procesaría dentro de media década. Ese es el tipo de retorno que no aparece en una ronda de financiación, pero sí en la cuenta de resultados.

Fuentes

• Rewinding the exponential: How we keep hardware usage down (fuente original)
• AWS, Google, Oracle, Microsoft Top Gartner's Cloud AI Infrastructure List For 2026
• AI's Absurd Spending Boom? Hyperscalers Are Spending 102% of Cloud Revenue on Capex
• How to manage cloud transfer and egress charges