Publicado el 13 de noviembre
Construyendo Conflux - Mi propio motor de colaboración en tiempo real en Rust
Siempre he usado herramientas en tiempo real sin pensar demasiado en cómo funcionan realmente. Google Docs, Figma, Replit multiplayer, VSCode Live Share… escribes algo, la otra persona lo ve instantáneamente, nada se rompe, nadie sobrescribe a nadie. Simplemente… funciona.
Y por alguna razón, siempre me preguntaba qué está pasando detrás de escena. ¿Cómo aparece misteriosamente el cambio de una persona en todas partes? ¿Cómo se manejan los conflictos? ¿Qué pasa si dos personas cambian la misma cosa al mismo tiempo?
No quería la respuesta “de alto nivel”. Quería sentir el sistema. De la misma manera en que construir Veridian me ayudó a entender Git, quería entender estos sistemas de sincronización en tiempo real construyendo uno yo mismo.
Así que construí Conflux, un pequeño motor de colaboración en tiempo real escrito en Rust. No porque el mundo necesite otro backend, sino porque yo necesitaba entender cómo estos sistemas en tiempo real sincronizan el estado entre múltiples usuarios sin explotar.
Resulta que no es alguna tecnología misteriosa. Es un conjunto de ideas simples apiladas limpiamente.
Por qué quise construir esto
Cada vez que veía a personas editando la misma cosa al mismo tiempo, mi cerebro simplemente asumía: “Bien, alguna biblioteca misteriosa está haciendo algo complicado”. Pero luego aprendí sobre CRDTs, y toda la idea encajó.
Un CRDT (Conflict-free Replicated Data Type) es básicamente una estructura de datos que nunca entra en conflicto. Cada actualización es fusionable. Todos pueden editar libremente sin bloqueos. Y eventualmente, todo converge al mismo estado.
Cuando me di cuenta de eso, quise verlo por mí mismo:
- ¿Cómo se ve realmente un sistema de colaboración basado en CRDT cuando lo implementas?
Lo “real” detrás de esto: ¿Qué es un CRDT?
Bien, desglosemos esto. La parte “sin conflictos” es la que importa.
La forma “normal” (el problema):
Imagina que tú y yo estamos editando un archivo de texto.
- Ambos descargamos el archivo. Dice:
"Hola". - Yo cambio mi copia a:
"Hola mundo". - Tú, al mismo tiempo, cambias tu copia a:
"Hola allí". - Yo subo mi versión. El servidor ahora tiene
"Hola mundo". - Tú subes tu versión. El servidor ahora tiene
"Hola allí".
Mi cambio se ha perdido. Para siempre. Me sobrescribiste. Esto es un conflicto. Esto es lo que los sistemas de control de versiones como Git pasan todo su tiempo intentando gestionar con “conflictos de fusión”.
La forma “CRDT” (la solución):
Los CRDT no funcionan así. No envían el archivo completo de ida y vuelta. Envían instrucciones.
- Ambos tenemos el estado:
"Hola". - Yo hago un cambio. Mi CRDT local no dice “el nuevo archivo es ‘Hola mundo’”. Genera una instrucción:
(En la posición 5, agregar: " mundo"). - Tú, al mismo tiempo, haces un cambio. Tu CRDT genera una instrucción:
(En la posición 5, agregar: " allí"). - Yo envío mi instrucción al servidor.
- Tú envías tu instrucción al servidor.
El servidor, y eventualmente todos los clientes, reciben ambas instrucciones. La “aura” del CRDT es que tiene una regla matemática para fusionar estas instrucciones de modo que todos terminen con el mismo estado final exacto.
El texto final podría ser "Hola mundo allí" o "Hola allí mundo". Lo importante es que ningún dato se perdió, y todos terminamos viendo lo mismo sin nunca recibir un error de “CONFLICTO DE FUSIÓN”.
Eso es todo. Un CRDT es simplemente una estructura de datos con un algoritmo de “fusión” tan bueno que nunca entra en conflicto.
Qué hace realmente Conflux
Ahora que sabemos qué es un CRDT, todo el sistema tiene más sentido.
Eliminemos los detalles adicionales, y Conflux hace tres cosas simples:
- Mantiene salas – como “documentos” o “sesiones”.
- Cada sala contiene un documento CRDT – esto almacena el estado compartido.
- Los clientes envían instrucciones (actualizaciones), el servidor las fusiona y las transmite a todos los demás.
Aquí está ese mismo ciclo, pero ahora tiene sentido:
Tú escribes algo → tu CRDT local genera una instrucción → envías esa instrucción (la “actualización”) al servidor → el servidor la fusiona en su propio CRDT → el servidor transmite esa instrucción a todos los demás clientes → sus CRDT locales la fusionan → la interfaz de usuario de todos se actualiza.
Eso es todo. Ese es todo el ciclo. Sin algoritmos sofisticados, sin transformaciones extrañas, sin líneas de tiempo ramificadas.
Solo: actualizar → fusionar → transmitir.
Y como los CRDT están diseñados para fusionarse limpiamente, nada entra en conflicto.
La arquitectura (versión simple)
Para facilitar la comprensión, lo dibujé:
Cada caja en este diagrama tiene un trabajo. Ninguna caja está haciendo cinco cosas a la vez. Y esa simplicidad es lo que hizo que todo el sistema se sintiera accesible.
Cómo está diseñado el servidor
El servidor Conflux tiene cuatro piezas principales, y cada una hace exactamente un trabajo.
1. Gestor de salas
Esta es la parte que lleva el registro de todas las salas activas.
Si una sala no existe, la crea. Si una sala está inactiva durante demasiado tiempo, la limpia.
Nada sofisticado: solo gestión del ciclo de vida.
2. Sala (bucle de actor)
Una sala es básicamente su propio mini-servidor.
Ejecuta un bucle que simplemente escucha comandos como:
ApplyUpdate(¡Esta es nuestra instrucción CRDT!)SetAwarenessChatJoinLeave
…y aplica esas actualizaciones a su propio YDoc.
Este diseño de “actor” significa que cada sala está aislada, lo que evita el caos habitual del estado compartido.
3. Servidor WebSocket
Este es el punto de entrada.
Hace lo siguiente:
- Autentica a los usuarios usando JWT.
- Extrae el ID de la sala de la URL.
- Actualiza la conexión a un WebSocket.
- Reenvía los mensajes entrantes a la sala correcta.
- Reenvía los mensajes salientes de la sala de vuelta al cliente.
Acepta dos tipos de mensajes:
- Texto plano: Esto se convierte en un mensaje de chat.
- JSON: Esto se convierte en una actualización estructurada de CRDT o de conciencia.
Esto facilita la depuración porque puedes escribir mensajes de chat literalmente desde un terminal.
4. Autenticación JWT
Cada inicio de sesión crea un nuevo ID de sesión (sid) dentro del token.
Esto soluciona el problema de “todos inician sesión con el mismo token”. Cuando un cliente se conecta, el servidor sabe:
- Qué usuario
- Qué sesión
- Qué sala
Es simple, pero proporciona un modelo de identidad limpio.
El flujo de sincronización (explicación sencilla)
Supongamos que dos personas están editando un documento compartido.
- La persona A edita algo. Su CRDT local aplica el cambio instantáneamente y genera una instrucción.
- A envía la instrucción (la actualización) al servidor. Esto es solo un pequeño fragmento binario.
- El servidor aplica la instrucción a su propio CRDT. Esto mantiene la copia del servidor del documento autoritaria.
- El servidor transmite la instrucción. Todos los otros clientes en esa sala reciben la misma actualización.
- Cada cliente la aplica. Su CRDT local fusiona la instrucción con lo que ya tienen.
- Todos permanecen sincronizados. Incluso si muchas personas cambian la misma cosa al mismo tiempo, el CRDT maneja las fusiones suavemente.
Suena complicado, pero verlo funcionar lo hace sentir simple.
Por qué la conciencia y el chat importan
Los sistemas en tiempo real no se tratan solo del contenido del documento.
Los usuarios necesitan saber:
- Quién más está en línea
- Dónde está su cursor
- Quién está escribiendo
- Quién se unió o salió
Así que agregué “eventos de conciencia”. Estos son solo pequeños mensajes JSON que se propagan instantáneamente para mostrar quién es quién y dónde está.
El chat fue simple: si el cliente envía texto normal en lugar de JSON, el servidor lo trata como un mensaje de chat y lo transmite.
Es una característica pequeña, pero hace que el sistema se sienta vivo.
El panel de control
También construí un pequeño punto final de panel de control:
GET /dashboard
Esto devuelve:
- ID de la sala
- Número de clientes conectados
- Número de actualizaciones del documento
- Número de eventos de conciencia
No es nada sofisticado, pero es increíblemente útil para ver cómo funciona el sistema.
Lo que aprendí al construir esto
Al igual que Veridian hizo que Git encajara para mí, Conflux hizo que la colaboración en tiempo real encajara.
Aquí están las cosas que destacaron:
- La sincronización en tiempo real se trata principalmente de ordenamiento de mensajes y transmisión.
- Los CRDT eliminan aproximadamente el 90% de los problemas de “conflicto”.
- Las salas de estilo actor hacen que la concurrencia sea sorprendentemente limpia.
- Los WebSockets son mucho más fáciles de usar de lo que esperaba.
- Tener un sistema de identidad adecuado desde el principio ahorra dolores de cabeza más adelante.
- La mayoría de los “sistemas complejos” son simplemente una cadena de pasos simples.
Antes de construir Conflux, estos sistemas se sentían como cajas negras.
Después de construirlo, se sienten como algo que puedo entender — e incluso mejorar.
Reflexiones finales
Conflux no es perfecto. Probablemente le falten características. Definitivamente no está listo para producción. Pero hace exactamente lo que lo construí para hacer y me ayudó a entender cómo funciona la colaboración en tiempo real detrás de escena.
Si tienes curiosidad por este tema, intenta construir una versión pequeña tú mismo.
No necesitas recrear Google Docs. Incluso un pequeño contador compartido basado en CRDT te enseñará mucho.
Puedes ver Conflux aquí: