¿CRDT u Operational Transform? ¿Cómo elegimos?

OT es una tecnología madura para la edición secuencial de texto (la usa Google Docs). Los CRDT funcionan mejor con datos estructurados, datos espaciales y sistemas en los que el servidor no siempre tiene la última palabra. La elección depende de tu modelo de datos: en la semana uno analizamos los pros y contras frente a tu esquema concreto.

¿Y Liveblocks o Yjs? ¿Por qué construir algo a medida?

Liveblocks, Yjs y Loro resuelven el 80 % del problema rápidamente, y te diremos si encajan con tu caso porque se lanzan antes. La sincronización a medida tiene sentido cuando tu modelo de datos tiene una semántica que la librería no puede expresar (por ejemplo, un canvas con operaciones no conmutativas) o cuando el precio de la capa gestionada no sale a cuenta a tu escala.

¿Cómo gestionáis que un usuario se quede sin conexión a media edición?

Las ediciones sin conexión se acumulan en un registro local de deltas CRDT, persistido en IndexedDB. Al reconectar, el delta se envía y se fusiona en el servidor. La fusión es determinista: no hay ningún diálogo de «¿qué versión quieres conservar?». El único caso límite son los borrados intencionados, que diseñamos como tombstones en lugar de como operaciones de eliminación.

Apps colaborativas en tiempo real

Apps colaborativas en tiempo real: sincronización en directo sin conflictos

Los usuarios esperan ver las ediciones de los demás al instante: sin recargar, sin conflictos y sin perder trabajo. Eso no es una funcionalidad que se añade a una API REST. Es una arquitectura de datos distinta, un modelo de consistencia distinto y un conjunto de modos de fallo distinto que la mayoría de las librerías de sincronización se limitan a esconder.

Cómo funciona un ciclo de sincronización CRDT

1
Edición local
El usuario A escribe: se aplica al estado local de forma optimista
2
Registro de operaciones
El cambio se registra como un delta CRDT, no como una instantánea completa
3
Difusión
El delta se envía a todos los pares conectados por WebSocket
4
Fusión
Cada par fusiona de forma determinista, sin diálogo de conflicto
5
Convergencia
Todos los clientes llegan al mismo estado, con consistencia eventual

Las ediciones sin conexión se encolan en local y se fusionan al reconectar con las mismas reglas deterministas.

Qué obtienes

Motor de sincronización CRDT u Operational Transform diseñado para tu modelo de datos concreto: texto, texto enriquecido, canvas, datos estructurados u objetos de dominio a medida

Capa de presencia: cursores en vivo, avatares, indicadores de escritura, estado de conexión y estado de foco, propagados en menos de 50 ms

Resolución de conflictos con una semántica de fusión definida: las ediciones simultáneas se fusionan de forma determinista y nunca se descartan en silencio

Soporte sin conexión con un modelo de estado local optimista y una estrategia de resolución de conflictos para fusionar los cambios offline al reconectar

Infraestructura de sincronización escalable (WebSocket, canales de datos WebRTC o una capa gestionada como Liveblocks, PartyKit o Loro cuando encaje) dimensionada para tus requisitos de concurrencia

Observabilidad del estado de sincronización: tasa de conflictos, latencia de fusión y tasa de clientes desactualizados, las métricas que te dicen si el tiempo real funciona de verdad a escala

Cuándo encaja

Varios usuarios trabajan a la vez en el mismo documento, canvas o estructura de datos
Los usuarios esperan que los cambios aparezcan sin recargar la página: el modelo «gana el último guardado» es un problema de experiencia de usuario, no una limitación asumida
Necesitas soporte sin conexión: tus usuarios trabajan en aviones y en sótanos, y su trabajo no debería desaparecer
La solución actual consiste en hacer polling cada N segundos y llamarlo «tiempo real»

Cuándo no

La colaboración es secuencial, no simultánea: la mayoría de los flujos en los que solo edita un usuario a la vez no necesitan CRDT, necesitan una interfaz optimista
El modelo de datos es de solo anexión (feeds de actividad, logs, chat): suelen bastar patrones más sencillos de event sourcing
Tu equipo nunca ha lanzado un producto en tiempo real: valora primero una capa gestionada (Liveblocks, Ably) y cuenta con nosotros cuando llegues a sus límites

Proceso

Semana 1: análisis del modelo de datos y catálogo de escenarios de conflicto; enumeramos todas las combinaciones de edición simultánea antes de escribir código. Semanas 2–5: implementación del motor de sincronización con un banco de pruebas que reproduce los escenarios de conflicto registrados. Semanas 6–9: capa de presencia, soporte sin conexión y pruebas de escala. Semana 10: paneles de observabilidad y runbooks.

Proceso de entrega completo

Precios

Precio cerrado según la complejidad del modelo de datos. Texto simple o enriquecido: $80–160k. Datos estructurados con reglas de fusión a medida: $150–350k. Canvas o espacial (estilo Figma): $200–500k. La integración con una capa gestionada (Liveblocks, Loro) es más rápida y barata, y te la recomendaremos con honestidad si encaja.

Ver modelos de colaboración

Sectores en los que aplicamos este servicio

Startups SaaS

EdTech y formación corporativa

Preguntas frecuentes

¿CRDT u Operational Transform? ¿Cómo elegimos?: OT es una tecnología madura para la edición secuencial de texto (la usa Google Docs). Los CRDT funcionan mejor con datos estructurados, datos espaciales y sistemas en los que el servidor no siempre tiene la última palabra. La elección depende de tu modelo de datos: en la semana uno analizamos los pros y contras frente a tu esquema concreto.
¿Y Liveblocks o Yjs? ¿Por qué construir algo a medida?: Liveblocks, Yjs y Loro resuelven el 80 % del problema rápidamente, y te diremos si encajan con tu caso porque se lanzan antes. La sincronización a medida tiene sentido cuando tu modelo de datos tiene una semántica que la librería no puede expresar (por ejemplo, un canvas con operaciones no conmutativas) o cuando el precio de la capa gestionada no sale a cuenta a tu escala.
¿Cómo gestionáis que un usuario se quede sin conexión a media edición?: Las ediciones sin conexión se acumulan en un registro local de deltas CRDT, persistido en IndexedDB. Al reconectar, el delta se envía y se fusiona en el servidor. La fusión es determinista: no hay ningún diálogo de «¿qué versión quieres conservar?». El único caso límite son los borrados intencionados, que diseñamos como tombstones en lugar de como operaciones de eliminación.

Dos compañeros de TekPiq trabajando en pareja con sus portátiles en la mesa de reuniones — Trabajando en pareja en la mesa de reuniones.

Quién lo construye

Nuestro propio equipo, que trabaja desde nuestra oficina en Istočno Sarajevo, Bosnia y Herzegovina. Los ingenieros de tu llamada para definir el alcance son quienes lo construyen.

Conoce al equipo

Apps colaborativas en tiempo real: ¿hablamos?

Llamada de 30 minutos para definir el alcance. Sin compromiso ni presión comercial.