Cloudflare ahorró 100 TB de RAM con matemáticas y Rust — y nadie está hablando de ello

Cloudflare acaba de liberar 100 TB de RAM en su red global. Y no compró más servidores ni optimizó a fuerza bruta: usó matemáticas y Rust. 🧠

Para que te hagas una idea: 100 TB de RAM son como 100 computadoras gamer de gama alta, solo en memoria. En los precios de hoy, hablamos de millones de dólares al año.

La compañía tiene miles de servidores alrededor del mundo, con petabytes de RAM y millones de núcleos de CPU. Todo al límite. Y de repente, un ingeniero encontró algo raro: su servicio de balanceo de carga, el Pingora Backend Router, consumía muchísima más memoria de la esperada.

El problema se llamaba pingora-ketama

La culpa era de su librería de hashing consistente, una de las piezas más aburridas — y más importantes — de cualquier infraestructura grande.

El hashing consistente decide qué servidor guarda cada archivo. Cada servidor y cada tarea se convierten en números, y cada tarea va al servidor "más cercano" en la línea numérica.

Suena simple, pero tiene un problema gigante: la distribución no es pareja.

Con 100 servidores, la variación entre la carga esperada y la real puede ser de hasta 99%. O sea: hay servidores trabajando el doble que otros mientras algunos están casi vacíos.

La solución clásica: más hashes

El truco de siempre es sencillo: agregar más hashes por servidor. NGINX y Pingora usan 160 por defecto. Con eso, el error cae de 99% a ~8%.

Pero Cloudflare no usa NGINX para esto: usa el algoritmo ketama, que multiplica los hashes por el peso de cada servidor (su espacio en disco). Con un factor de peso de 625, un servidor pasa a tener 100,000 hashes en memoria.

Y aquí está el hallazgo: los últimos 90,000 hashes apenas mejoran la precisión en 0.7%. Pero ocupan memoria. Y con tantos hashes en un espacio de 32 bits, las colisiones empiezan a aparecer e introducen errores (el clásico birthday paradox).

La matemática dijo: reduce los hashes en 90% sin pérdida apreciable de precisión. Y se hizo.

Un struct más flaco = 25% menos

Pero había más grasa. El struct de Rust que guarda cada punto usaba un índice de 4 bytes. Como Cloudflare jamás tendrá más de 65,000 servidores simultáneos, lo bajaron a 2 bytes.

Un detalle: Rust tiene reglas de alineación, así que no basta con cambiar el tipo. Guardaron hash e índice como un array de bytes crudo de 6 bytes con getters. Molesto de leer, pero el mismo resultado compilado. Solo eso ahorró 25% de la memoria del hashing.

Menos hashes + estructuras más flacas = 100 TB de RAM libres 💾. Y no es la primera vez: el mes pasado el equipo de DNS ya había liberado otros 100 TB.

Lo mejor: la migración sin incendiar el mundo

Lo más impresionante no es el número. Es la forma de aplicarlo. Cloudflare no hizo un "flip" global — eso habría invalidado el caché de todo el internet y disparado el tráfico a los orígenes.

Corrieron ambas versiones del anillo en paralelo y fueron moviendo tráfico por centro de datos, con rollback limpio en cada paso. Trabajo aburrido, resultado monumental.

Lo que me encanta de esta historia es que no hay chip nuevo ni IA mágica. Hay gente mirando sus propios números y viendo dónde sobra grasa.

Tu código tiene la misma grasa. Ese struct con un campo de 4 bytes que podría ser de 2. Ese índice que nadie revisó. Esa configuración por defecto que nunca cuestionaste. Cloudflare encontró 100 TB en detalles aburridos.

La librería pingora-ketama ya tiene el anillo v2 disponible como feature de Cargo: almacenamiento compacto, ordenamiento más rápido y hashes escalables. Si usas Rust para balancear carga, puedes probarlo hoy.

Comparte esto con ese amigo que sigue metiendo hashes a lo loco sin mirar los números. 🔄

¿Cuánta RAM crees que desperdicia tu servidor en estructuras mal pensadas? Déjalo en los comentarios. 👇