Discord y Dropbox: dos migraciones a Rust y lo que enseñan

Antes de que Rust apareciera en los anuncios de Microsoft o Google, dos empresas medianas ya lo habían probado en producción y lo contaron con detalle. Sus casos siguen siendo los mejores para entender cuándo una migración vale la pena.

Discord: el problema de las pausas

Discord tiene un servicio llamado Read States: recuerda qué mensajes leyó cada usuario en cada canal. Se consulta cada vez que alguien se conecta, envía o lee un mensaje. Estaba escrito en Go.

El problema aparecía como un reloj: cada dos minutos, la latencia y el uso de CPU se disparaban. Era el recolector de basura de Go, que obligatoriamente recorría toda la memoria caché, con decenas de millones de registros, al menos cada dos minutos. Ajustar el recolector no sirvió.

Reescribieron el servicio en Rust. La primera versión, sin optimizar, ya no tenía picos y superaba a la versión de Go ajustada a mano. Tras optimizarla, Rust fue mejor en latencia, CPU y memoria. Explicamos este efecto en recolector de basura frente a Rust.

Pero Discord dejó una advertencia clara: no creen que haya que reescribir todo en Rust «solo porque sí».

Rust dentro de Elixir

Discord también usa Rust como acelerador. Su backend está en Elixir, donde los datos no se modifican, sino que se copian. Para listas de cientos de miles de miembros, eso era lento.

En lugar de reescribir el servicio, crearon una estructura en Rust que Elixir llama directamente:

La migración de billones de mensajes

En 2022, Discord migró su base de mensajes de Cassandra a ScyllaDB y puso servicios de datos en Rust entre su API y la base. Esos servicios agrupan peticiones idénticas en una sola consulta.

El migrador, reescrito en Rust, procesaba hasta 3,2 millones de mensajes por segundo. Bajó la estimación de tres meses a nueve días. El clúster pasó de 177 nodos a 72.

Dropbox: el problema de la corrección

El caso de Dropbox es distinto. Su motor de sincronización, escrito en Python, funcionaba, pero era casi imposible de cambiar sin romper algo: los errores de concurrencia eran difíciles de reproducir y formar a un ingeniero nuevo tomaba años.

Durante cuatro años lo reescribieron en Rust. La razón principal no fue la velocidad:

«Podemos codificar invariantes complejas de nuestro sistema en el sistema de tipos, y que el compilador las verifique por nosotros.»

Lo complementaron con pruebas aleatorias deterministas: cada noche ejecutan decenas de millones de escenarios simulados, con fallos de red y de disco inyectados, y cualquier error se puede reproducir exactamente.

Dropbox llamó a Rust «un multiplicador de fuerza» para el equipo. Y también advirtió que en muchos entornos una reescritura así sería una pésima idea.

El error que no repetirían

Un ingeniero que lideró el almacenamiento de Dropbox contó otra lección. Años antes, unos pocos ingenieros reescribieron en Rust el motor de almacenamiento mientras el resto seguía en Go. Funcionó, con menos CPU y memoria, pero el equipo quedó partido en dos durante años, y el conocimiento se perdió cuando esos autores se fueron.

En el motor de sincronización hicieron lo contrario: todo el equipo aprendió Rust. Lo llama un éxito sin reservas.

Qué enseñan los dos casos

Tres reglas que se repiten:

1. Hay un problema medible antes de la decisión. Picos cada dos minutos, errores imposibles de reproducir.
2. Se cambia una pieza, no todo. Ninguna empresa reescribió su producto entero.
3. El equipo completo aprende. Una isla de expertos es un riesgo, no una ventaja.

Antes de decidir en tu equipo, revisa las cinco preguntas antes de migrar.