Sincronización en tiempo real con CRDTs: El fin de los conflictos de edición

La mayoría de los desarrolladores intentan resolver la concurrencia con bloqueos de base de datos o WebSockets ingenuos que fallan en cuanto el usuario entra en un túnel del Metro de Medellín y pierde la conexión. El resultado es el temido 'Last Write Wins' (el último que escribe gana), donde el trabajo de un usuario sobrescribe el de otro sin previo aviso. Para construir aplicaciones verdaderamente colaborativas como Figma o Notion, necesitamos pasar del modelo de 'petición-respuesta' a los Conflict-free Replicated Data Types (CRDTs).

¿Qué son los CRDTs y por qué deberían importarte?

Un CRDT es una estructura de datos que puede replicarse en múltiples computadoras a través de una red, donde cada réplica puede actualizarse de forma independiente y concurrente sin necesidad de coordinación central. La magia ocurre al final: cuando las réplicas se ven de nuevo, existe un algoritmo matemático que garantiza que converjan en el mismo estado exacto.

A diferencia de Operational Transformation (OT) —la tecnología detrás de Google Docs que requiere un servidor central complejo y costoso— los CRDTs son descentralizados por naturaleza. Esto permite arquitecturas Local-First, donde la aplicación funciona al 100% sin internet y sincroniza cambios de forma eficiente cuando la red vuelve a estar disponible.

Tipos de CRDTs: De contadores a texto enriquecido

No todos los datos se comportan igual. Para implementar una arquitectura sólida, debemos elegir la estructura correcta para el tipo de información que manejamos:

• G-Counter (Grow-only Counter): Un contador que solo aumenta. Útil para métricas de visualizaciones o likes.
• PN-Counter (Positive-Negative Counter): Permite incrementos y decrementos, ideal para carritos de compra.
• LWW-Element-Set (Last Write Wins): El más simple, pero propenso a pérdida de datos si no se maneja con timestamps precisos.
• Text/Sequence CRDTs: Estructuras complejas para editores de código o texto donde el orden de los caracteres importa.

"La consistencia eventual no es un error de diseño, es una propiedad fundamental de los sistemas distribuidos que priorizan la disponibilidad sobre el bloqueo total."

Implementación técnica: Comparativa de Stacks

Si estás construyendo una aplicación moderna en 2024, no deberías escribir tus propios algoritmos de CRDT desde cero a menos que seas un doctor en matemáticas. Aquí están las herramientas líderes en el mercado:

1. Yjs: El estándar de facto para el ecosistema JS

Yjs es increíblemente rápido y eficiente en memoria. Se integra perfectamente con ProseMirror, Quill y Monaco Editor. Su modelo de red es agnóstico; puedes usar WebRTC para P2P o WebSockets para un modelo cliente-servidor.

import * as Y from 'yjs';
import { WebrtcProvider } from 'y-webrtc';

const ydoc = new Y.Doc();
const provider = new WebrtcProvider('room-name', ydoc);
const ytext = ydoc.getText('content');

ytext.observe(event => {
  console.log('Cambio detectado:', ytext.toString());
});

2. Automerge: Enfoque en JSON

Desarrollado originalmente por Ink & Switch, Automerge trata todo tu estado como un objeto JSON. Es más fácil de razonar para aplicaciones de gestión de tareas o CRMs, aunque históricamente ha sido un poco más lento que Yjs en documentos masivos.

Arquitectura Offline-First: El flujo de trabajo

Para implementar esto en un entorno real (por ejemplo, una App de logística en zonas rurales de Colombia con baja conectividad), el flujo debe ser el siguiente:

1. Persistencia Local: Los cambios se guardan primero en IndexedDB (navegador) o SQLite (móvil).
2. Propagación de Deltas: No enviamos todo el documento, solo el 'diff' binario generado por el CRDT.
3. Resolución Automática: Al recibir cambios remotos, el CRDT integra los nodos sin intervención del usuario.
4. Compactación: Periódicamente se limpian los metadatos antiguos para evitar que el archivo crezca indefinidamente.

Consideraciones de Seguridad y Privacidad

Al mover la lógica de mezcla al cliente, surgen retos. ¿Cómo validamos que un usuario no insertó datos maliciosos en su réplica local antes de sincronizar? La respuesta suele implicar el uso de firmas criptográficas por cada operación y servidores de 'relay' que validan esquemas sin necesariamente tener que entender el contenido del CRDT si usamos cifrado de extremo a extremo (E2EE).

Herramientas recomendadas para producción

• Hocuspocus: Un backend listo para usar para Yjs (basado en Node.js).
• Replicache: Una alternativa comercial extremadamente pulida para sincronización de UI.
• ElectricSQL: Para quienes necesitan sincronizar Postgres directamente con el dispositivo local usando CRDTs bajo el capó.

Cómo lo abordamos en Julsmind SAS

En Julsmind SAS, entendemos que la latencia mata la adopción de producto. Hemos implementado arquitecturas local-first para clientes que operan en condiciones de red inestables en toda LATAM. No solo tiramos código; diseñamos la topología de datos para que la experiencia del usuario sea instantánea (0ms de latencia percibida), utilizando CRDTs y optimizando la transferencia de binarios para reducir costos de infraestructura en la nube. Nuestra experiencia en Medellín nos ha enseñado que el software debe ser resiliente por diseño, no por accidente.

¿Estás cansado de los conflictos de guardado en tu plataforma actual o quieres llevar la colaboración en tiempo real al siguiente nivel? Hablemos sobre cómo una arquitectura de datos moderna puede transformar tu producto. Escríbenos en nuestra sección de contacto y analicemos tu caso técnico hoy mismo.