Por qué 100 TB de RAM importan incluso si no operas un resolver DNS
El equipo detrás de 1.1.1.1, el resolver DNS público de Cloudflare, ejecuta una plataforma interna llamada Big Pineapple que sostiene servicios como Gateway DNS, DNS Firewall y AS112. En estado estable, esa plataforma almacena más de 250 mil millones de entradas de caché. A esa escala, según el post técnico publicado por Cloudflare, desperdiciar un solo byte por entrada cuesta más de 250 GB de memoria repartidos por toda su flota.
Tras aplicar cinco cambios sucesivos al formato en que se almacenan las entradas, el equipo redujo la huella por entrada en más del 50% y liberó aproximadamente 100 TB de memoria, equivalente a la RAM de 130 servidores Gen 13 de la propia compañía. La mejora no salió gratis en rendimiento: al revés, las inserciones subieron un 43% y la latencia de lectura cayó un 19%.
Para un founder esto no es una anécdota de sysadmins. Es un caso de estudio sobre cómo se optimiza infraestructura de alto tráfico y qué decisiones de arquitectura pagan —o cuestan— cuando tu producto escala.
👥 ¿Quieres ir más allá de la noticia?
En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.
👥 Unirme a la comunidadLas cinco optimizaciones que liberaron esos 100 TB
Cloudflare no recurrió a un truco mágico. Aplicó cinco cambios incrementales, cada uno medido con un benchmark que reproducía el tráfico real: 56% registros A, 25% AAAA y 19% TXT, con entre uno y cuatro registros por entrada. Estos son, en orden de aparición en el post original.
1. Reemplazar Vec<T> y String por Box<[T]> y Box<str>
En Rust, un Vec<T> guarda tres campos: puntero a los datos en el heap, longitud actual y capacidad total. Como las entradas de caché DNS nunca se modifican tras guardarse, el campo capacity no sirve para nada pero cuesta 8 bytes por Vec. Lo mismo ocurre con String. Cada entrada contenía 8 campos Vec y String; cambiarlos por versiones boxed eliminó 8 bytes por campo, 64 bytes por entrada, y eliminó la memoria reservada de más en el heap. Cloudflare estima más de 15 TB liberados solo con este cambio.
2. Menos listas, más offsets
Las secciones de respuesta, autoridad y adicionales de un registro DNS se guardaban en listas separadas. Consolidarlas en una sola lista con offsets u16 al inicio de cada sección eliminó dos punteros de 8 bytes y dos largos de 8 bytes, reemplazados por dos offsets de 2 bytes: 28 bytes ahorrados por entrada. Además, eliminar campos pequeños redujo el padding de alineación de Rust, que en algunos casos comprimió aún más el struct.
3. Eliminar el owner redundante del registro
Cada registro DNS tiene un owner (el dominio al que pertenece). En la mayoría de los casos ese owner es idéntico al dominio consultado, así que guardarlo duplica información que ya está en la clave de caché. Cloudflare cambió el campo a Option<Box<Name>>: cuando es None, el owner se reconstruye desde la clave al construir la respuesta; cuando difiere (típico detrás de un CNAME), se guarda el nombre completo. En la práctica, la mayoría de los registros cacheados no necesitan esa asignación en el heap.
4. Boxear las variantes grandes del enum RecordData
El enum que representa los datos de un registro en Rust siempre ocupa el tamaño de su variante más grande: NAPTR, con 136 bytes más padding, llevaba el enum completo a 144 bytes. Como un registro A solo necesita 4 bytes y un AAAA 16, el relleno desperdiciado era enorme, sobre todo porque A y AAAA suman más del 80% del tráfico. Boxear las variantes grandes movió su contenido a una asignación aparte; el enum pasó a guardar solo un puntero de 8 bytes. Para A y AAAA, 120 bytes menos por registro.
5. Guardar los registros en wire format
La última optimización fue la más radical: en lugar de mantener los registros como variantes parseadas de un enum, Big Pineapple los almacena como un único Box<[u8]> con cada registro precedido por su longitud en 2 bytes. Eso elimina el overhead por variante y las asignaciones heap separadas, mejora la localidad de caché de CPU (los datos quedan contiguos) y permite copiar los bytes directamente al construir respuestas para A, AAAA, TXT y todos los tipos DNSSEC. Solo los registros con nombres (CNAME, NS, MX, SOA) requieren parseo adicional para aplicar name compression. En benchmark, este cambio redujo la latencia de lookup otro 5%.
Resultados medidos en producción, no solo en benchmark
El rollout se hizo en oleadas: arrancó el 18 de mayo de 2026 y completó en todos los servicios el 6 de julio de 2026. Cloudflare midió memoria residente real, no solo memoria del caché aislada.
| Métrica | Antes | Después | Cambio |
|---|---|---|---|
| Huella por entrada | 953 bytes | 420 bytes | -56% |
| Asignaciones por entrada | 1,1 KB | 461 bytes | -58% |
| Throughput de inserción | 625.000/s | 893.000/s | +43% |
| Latencia de lookup | 828 ns | 670 ns | -19% |
A nivel de instancia, la memoria cayó de 9,3 GB a 5,3 GB en el percentil 99 (reducción del 43%) y de 6,5 GB a 3,8 GB en el percentil 90 (42%). Las instancias con caché más poblada vieron los ahorros absolutos más grandes.
¿Qué significa esto para tu startup?
El caso de Cloudflare es ajeno a tu stack si vendes un SaaS para contabilidad, pero el método es directamente trasladable cuando tu producto empiece a generar datos a escala.
Acción 1 — Perfila memoria antes de comprar más RAM. Cuando notes presión de memoria en producción, no respondas con un upgrade de servidor. Instrumenta primero: contadores por tipo de estructura, tamaños por entrada y ratios de asignación. El problema suele estar en cómo serializas datos, no en cuánta RAM tienes. Una reducción del 50% en la huella por entrada, como logró Cloudflare, equivale literalmente a duplicar la capacidad del sistema sin gastar un euro en infraestructura.
Acción 2 — Trata el layout de memoria como un feature, no como un detalle. Cambiar Vec<T> por Box<[T]>, consolidar listas en offsets o almacenar datos en wire format son optimizaciones de bajo riesgo cuando tus estructuras son inmutables. No son específicas de Rust: cualquier lenguaje con un esquema de objetos fijo te permite tomar decisiones similares. Lo importante es decidirlo a tiempo, cuando la base de código todavía es maleable, y no cuando migrar el formato cuesta más que comprar memoria.
Acción 3 — Mide en producción, no solo en benchmark. Cloudflare construyó un benchmark que aproximaba el tráfico real (56% A, 25% AAAA, 19% TXT) y aún así aclara que los resultados de producción fueron distintos porque la memoria residente incluye otros procesos. Lección para founders: cualquier optimización crítica debe validarse con métricas en producción durante el rollout, no quedarse en el test sintético.
Como cierre, el propio equipo de Cloudflare anunció que planea reinvertir la memoria liberada en aumentar la capacidad de la caché sin aumentar su consumo, lo que mejora las tasas de acierto y reduce las consultas hacia upstream. Optimizar no termina en ahorrar costos: empieza en qué haces con lo que ahorraste.
Fuentes
- How we saved 100 terabytes of memory by optimizing 1.1.1.1's DNS cache — Cloudflare Blog (fuente original)
- Cloudflare says 1.1.1.1 outage not caused by attack or BGP hijack — BleepingComputer
👥 ¿Quieres ir más allá de la noticia?
En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.
👥 Unirme a la comunidad
