CRDT: cómo sincronizar datos sin servidor para arbitrar conflictos

Imaginemos a dos usuarios editando el mismo documento en planos diferentes, sin internet. Cada uno cambia el mismo campo. Cuando aterrizan y los dispositivos se sincronizan, alguien debe decidir qué versión gana. La respuesta tradicional era simple y brutal: el último en guardar sobrescribe al anterior. El otro pierde su trabajo y ni siquiera se da cuenta.

Este es el problema central de cualquier aplicación local. Los datos residen primero en el dispositivo, la edición se realiza fuera de línea y la conciliación ocurre después. La cuestión no es si habrá conflicto, sino cómo fusionar dos verdades divergentes sin perder información y, idealmente, sin depender de un servidor central que actúe como juez. Los CRDT son la respuesta matemática más elegante que tenemos para esto.

Qué es una CRDT, sin misticismos

CRDT significa tipo de datos replicados sin conflictos. El nombre asusta más que el concepto. En la práctica, se trata de una estructura de datos diseñada para que se puedan editar múltiples copias de forma independiente y, cuando se encuentran, convergen automáticamente al mismo estado final, sin coordinación previa.

La palabra clave es convergencia. No importa el orden en que llegan los cambios, ni cuántas veces se aplica el mismo cambio, ni cuántos saltos ha pasado por la red. Si dos dispositivos ven el mismo conjunto de operaciones, terminan siendo idénticos. Esta garantía es matemática, no una promesa de buena voluntad del código.

Para lograr esto, las operaciones de un CRDT deben tener tres propiedades. Son conmutativos, por lo que el orden no cambia el resultado. Son asociativos, por lo que no importa la agrupación. Y son idempotentes, por lo que aplicar lo mismo dos veces no causa daño. Las estructuras que respetan estas reglas forman lo que las matemáticas llaman semired, y de aquí proviene la garantía de convergencia.

Por qué esto resuelve el problema de lo local primero

Sin CRDT, la sincronización sin conexión requiere un árbitro. Normalmente, un servidor que recibe todas las versiones, aplica cualquier regla, a menudo la infame última escritura gana, y devuelve la verdad oficial. Esto tiene dos costos. La pérdida de datos al sobrescribir y la dependencia de un punto central siempre online para resolver cualquier divergencia.

Los CRDT disuelven esta dependencia. Debido a que la fusión es determinista y está integrada en la propia estructura, cualquier dispositivo puede fusionarse con cualquier otro, en cualquier topología. Dos móviles se pueden sincronizar directamente vía Bluetooth, tres réplicas pueden encajar en una malla y el resultado es el mismo que con un servidor coordinándolo todo. El servidor, cuando existe, se convierte simplemente en un conveniente relevo, no en una autoridad.

Esto cambia la naturaleza de la aplicación. El usuario no espera una respuesta de la red para ver aplicada su edición, porque la verdad local ya es válida. La sincronización ocurre en segundo plano y nunca vuelve diciendo "tu trabajo ha sido descartado". Es lo que hace que la experiencia de la aplicación como editores colaborativos modernos sea tan fluida, y es la base técnica de cualquier arquitectura seria que priorice lo local.

Los sabores CRDT que encontrarás

Dominan dos estilos principales. Los CRDT basados en estado intercambian toda la estructura entre réplicas y utilizan una función de fusión para combinar. Son simples de razonar, pero pesan mucho en la red cuando los datos crecen. Los basados en operaciones o basados en operaciones propagan solo cambios individuales, lo cual es más económico, pero requiere una capa de entrega de operaciones confiable.

Sobre estos estilos hay un catálogo de tipos confeccionados. Contadores que suman incrementos de múltiples réplicas sin perder ninguna. Conjuntos que saben mezclar altas y bajas de forma coherente, como OR-Set. Y el caso más codiciado, el texto secuencial, donde cada carácter recibe un identificador único y ordenable para que las inserciones en competencia no se superpongan entre sí. Algoritmos como Yjs y Automerge empaquetan todo esto en bibliotecas que puedes usar sin volver a implementar la teoría.

La buena noticia para los responsables de la toma de decisiones en arquitectura es que rara vez se escribe un CRDT desde cero. Usted elige la biblioteca, modela sus datos según los tipos que ofrece y recibe la convergencia como regalo. El trabajo intelectual consiste en mapear el dominio de estas estructuras, no en demostrar teoremas.

Donde realmente brillan las CRDT

Son imbatibles cuando la regla de fusión es genuinamente neutral, es decir, cuando mantener ambas ediciones es siempre el comportamiento correcto. El texto colaborativo es el ejemplo perfecto: si dos personas escriben párrafos diferentes, querrás ambos párrafos, punto. Las listas, los tableros kanban, las notas, los dibujos vectoriales y la mayoría de las herramientas de productividad colaborativa entran en esta categoría.

También brillan en escenarios donde la conectividad es deficiente o intermitente por naturaleza. Aplicaciones de campo, recopilación de datos en zonas remotas, dispositivos que pasan horas sin conexión. En las aplicaciones [primero sin conexión], CRDT es lo que le permite trabajar con total confianza de que no se perderá nada en la siguiente sincronización. La convergencia automática es exactamente la garantía que estos contextos requieren.

Y brillan cuando se quiere eliminar el servidor de la ruta crítica. Arquitecturas peer-to-peer, mallas locales, sincronización entre dispositivos de un mismo usuario sin pasar por la nube. Todo esto es viable porque la inteligencia fusionada reside en los datos, no en la infraestructura.

Donde no son la respuesta correcta

Esta es la parte que a menudo se esconde debajo de la alfombra. Los CRTD convergen a un estado válido, pero no necesariamente al estado que su empresa considera correcto. La convergencia no es sinónimo de reglas de negocio satisfechas. Si dos personas reservan el último asiento en un vuelo fuera de línea, CRDT fusionará ambas reservas y tendrá una garantía matemática de sobreventa.

Los conflictos que requieren una decisión semántica no pertenecen a CRDT. Equilibrio que no puede ser negativo, unicidad de un campo, aprobación que invalida otro, cualquier invariante que necesite un “no, eso no puede suceder” quiere un verdadero árbitro. En estos casos, la regla de negocio necesita decidir el conflicto, y tratar de llevar esto a la capa de datos produce errores sutiles y costosos.

También está el costo de la memoria y el almacenamiento. Para garantizar la convergencia, muchos CRDT almacenan metadatos que crecen con el historial de edición. Se eliminaron lápidas de elementos, identificadores por carácter y vectores de versión. Sin estrategias de compactación, una estructura aparentemente pequeña puede hincharse hasta niveles sorprendentes. No todos los problemas se convierten en CRDT de forma económica, y no todos los problemas deberían convertirse en CRDT.

Mi recomendación como CTO es pragmática. Utilice CRDT donde la combinación es naturalmente aditiva y la ganancia de experiencia es real. Cuando la corrección dependa de una invariante empresarial, acepte un árbitro, ya sea un servidor, una cola de comandos o un flujo de resolución explícito presentado al usuario. El error más común es tratar a CRDT como una solución milagrosa y descubrir overbooking en producción.