Colaboración en Tiempo Real en Diseño de Base de Datos: Cómo Los CRDTs Lo Hacen Posible

La colaboración en tiempo real suena simple en teoría: dos personas editan el mismo documento al mismo tiempo, y ambos ven los cambios del otro instantáneamente. En la práctica, es uno de los problemas más difíciles en sistemas distribuidos. ¿Qué sucede cuando dos desarrolladores agregan una columna a la misma tabla simultáneamente? ¿Y si una persona elimina una tabla mientras otra está agregando relaciones a ella? ¿Y si alguien se desconecta, hace cambios, y vuelve?

Estos no son casos extremos hipotéticos. Son escenarios cotidianos cuando un equipo trabaja en un schema de base de datos junto. La tecnología que los resuelve elegantemente se llama CRDTs — Conflict-free Replicated Data Types. Aquí te mostramos cómo funcionan y por qué importan para la colaboración en diseño de base de datos.

El Problema con la Colaboración Ingenua

El enfoque más simple para colaboración es "la última escritura gana." Dos personas hacen cambios, y whoever saves last "gana," y los cambios de la otra persona se pierden o se relegan a un archivo de conflicto.

Un enfoque ligeramente mejor es operational transformation (OT), utilizado por Google Docs. OT rastrea operaciones (insertar carácter en posición 5, eliminar carácter en posición 10) y las transforma cuando ocurren conflictos. Si Alice inserta un carácter en posición 5 y Bob inserta uno en posición 10, OT ajusta la posición de Bob para tener en cuenta la inserción de Alice. Esto funciona bien para documentos de texto.

Pero los schemas de base de datos no son documentos de texto. Son objetos estructurados con relaciones complejas. Una operación de schema no es "insertar carácter en posición 5" — es "agregar columna email de tipo VARCHAR(255) con una constraint unique a la tabla users." Las relaciones entre operaciones son semánticas, no posicionales. El enfoque orientado al texto de OT no se traduce bien a datos estructurados.

Entra CRDT

Los CRDTs adoptan un enfoque fundamentalmente diferente. En lugar de transformar operaciones después de conflictos, diseñan estructuras de datos que están garantizadas matemáticamente para converger — significando que sin importar qué orden lleguen las operaciones, todos los pares terminan con el mismo estado. Sin necesidad de resolución de conflictos, porque los conflictos literalmente no pueden ocurrir.

Esta garantía viene de las propiedades matemáticas de las estructuras de datos mismas. Un CRDT se diseña para que las operaciones sean conmutativas (el orden no importa), asociativas (la agrupación no importa), e idempotentes (aplicar la misma operación dos veces no tiene efecto adicional).

Cómo funciona esto en la práctica

Imagina que Alice y Bob están ambos editando un schema de base de datos. Alice agrega una columna phone a la tabla users. Bob agrega una columna avatar_url a la misma tabla al mismo tiempo. Ninguno sabe aún del cambio del otro.

Con CRDTs, ambas operaciones se representan como adiciones independientes a una estructura de datos compartida. Cuando el cambio de Alice llega a Bob y el cambio de Bob llega a Alice, ambos terminan con una tabla users que tiene ambas columnas phone y avatar_url — sin importar cuál cambio llegó primero. El CRDT garantiza convergencia.

¿Qué pasa con las eliminaciones? Si Alice elimina la tabla profiles mientras Bob agrega una columna a ella, el CRDT resuelve esto de forma determinista. La resolución típica es que las eliminaciones toman precedencia (la tabla se elimina, y la adición de columna de Bob se descarta silenciosamente) o las adiciones toman precedencia (la tabla sobrevive con la nueva columna, y la eliminación de Alice se revierte). La política específica es una elección de diseño, pero el punto clave es que todos los pares alcanzan el mismo estado automáticamente.

Yjs: El Framework CRDT

ER Flow utiliza Yjs, una de las implementaciones de CRDT más maduras y probadas en batalla disponibles. Yjs proporciona tipos de datos compartidos (maps, arrays, text) que se sincronizan automáticamente entre pares, soporte sin conexión (los cambios se encolan y se sincronizan cuando la conectividad retorna), protocolo de awareness (posiciones de cursor e información de presencia), y una codificación binaria eficiente que minimiza el ancho de banda de red.

Yjs ha sido adoptado por herramientas colaborativas principales y ha probado su confiabilidad a escala. Para colaboración de schema de base de datos, los tipos de datos relevantes de Yjs son Y.Map para definiciones de tabla (nombres de columna, tipos, constraints), Y.Array para listas ordenadas (orden de columna dentro de una tabla), y Y.Maps anidados para estructuras complejas (un schema es un map de tablas, cada tabla es un map de columnas, cada columna es un map de propiedades).

Lo Que Esto Significa para Equipos de Diseño de Base de Datos

Edición verdaderamente simultánea

Múltiples miembros del equipo pueden trabajar en diferentes partes del schema al mismo tiempo sin coordinación. Un desarrollador agrega las tablas de autenticación mientras otro diseña el schema de facturación. Los cambios aparecen en el canvas de todos en tiempo real — típicamente dentro de 50-100 milisegundos en una conexión decente.

Resiliencia sin conexión

Si un desarrollador pierde conectividad (común en laptops, en cafés, o en trenes), pueden continuar trabajando en el schema. Cuando la conectividad retorna, Yjs sincroniza automáticamente sus cambios sin conexión con el servidor y otros pares. El CRDT garantiza que el merge es consistente, sin importar cuántos cambios se hicieron sin conexión o por otras personas mientras estaban desconectados.

Sin sobrecarga de coordinación

Sin CRDTs, los equipos necesitan coordinar quién está editando qué: "Estoy trabajando en la tabla de usuarios, no la toques." Este bloqueo implícito ralentiza la colaboración y crea cuellos de botella. Con CRDTs, no hay necesidad de coordinación — todos pueden editar cualquier cosa, y el sistema maneja convergencia automáticamente.

Presencia de cursor y conciencia

Más allá de sincronización de datos, el protocolo de awareness de Yjs impulsa seguimiento de cursor en tiempo real. Puedes ver dónde están otros miembros del equipo en el canvas, qué están seleccionando, y qué están editando. Esta conciencia compartida reduce confusión y hace que la colaboración remota se sienta tan natural como trabajar lado a lado.

Los Detalles Técnicos (Para los Curiosos)

Escenarios de conflicto y resolución

Aquí te mostramos cómo ER Flow maneja escenarios de conflicto específicos con CRDTs.

Dos personas editan la misma columna simultáneamente. Si Alice cambia el tipo de columna a TEXT mientras Bob lo cambia a VARCHAR(500), el CRDT resuelve esto usando una regla determinista (típicamente la operación con la timestamp lógica más alta gana). Ambos pares convergen al mismo valor. En la práctica, este escenario es raro porque las características de awareness muestran qué otros están editando, previniendo naturalmente ediciones simultáneas a la misma propiedad.

Una persona elimina una tabla mientras otra la modifica. La eliminación gana — la tabla se elimina, y la modificación se descarta. Esto sigue el principio de menos sorpresa: si alguien eliminó explícitamente la tabla, preservarla por una edición concurrente sería confuso.

Dos personas crean tablas con el mismo nombre simultáneamente. Cada tabla obtiene un ID interno único, por lo que las colisiones de nombre a nivel CRDT no ocurren. La UI puede marcar el nombre duplicado para que los usuarios lo resuelvan.

Características de rendimiento

Yjs está altamente optimizado para rendimiento. La codificación binaria es compacta — una operación de schema típica (agregar una columna) produce un mensaje de sincronización de aproximadamente 50-200 bytes. La sincronización de estado inicial para un schema de 100 tablas toma menos de 100 milisegundos. El uso de memoria es proporcional al tamaño del documento, no a la longitud del historial — Yjs realiza garbage collection en operaciones fusionadas.

Para colaboración de schema de base de datos, donde las estructuras de datos son relativamente pequeñas (comparado con, digamos, un documento de texto compartido con millones de caracteres), el rendimiento de Yjs es más que adecuado. Incluso schemas con cientos de tablas y miles de columnas se sincronizan casi instantáneamente.

Más Allá de la Edición en Tiempo Real

Los CRDTs habilitan features que van más allá de la edición simultánea básica.

Branching y merging de schemas. Porque los CRDTs garantizan convergencia, puedes crear "branches" independientes de un schema (similar a branches de Git), hacer cambios independientemente, y mergearlos de vuelta — con el CRDT manejando convergencia automáticamente. Esto abre flujos de trabajo como diseño de schema de feature-branch, donde cada desarrollador experimenta con cambios de schema independientemente y mergea cuando está listo.

Viaje en el tiempo. Las operaciones de CRDT pueden almacenarse como un log, habilitando reproducción de la evolución del schema a lo largo del tiempo. ¿Quieres ver cómo se veía el schema hace tres semanas? Reproduce operaciones hasta esa timestamp.

Importación sin conflictos. Cuando importas un schema desde SQL, las operaciones de importación son operaciones CRDT. Esto significa que importar en un schema que otros están activamente editando funciona correctamente — las tablas importadas se mergean con cambios en vivo sin conflictos.

Por Qué Esto Importa

Para equipos acostumbrados al diseño de schema basado en archivo (pasando archivos .sql o diagramas draw.io), la colaboración basada en CRDT en tiempo real es un cambio de escala. El schema de base de datos se convierte en un documento vivo que todo el equipo puede trabajar simultáneamente, con la confianza de que cambios concurrentes siempre convergerán a un estado consistente.

Combinado con diseño visual, asistencia de IA, y generación de migration, la colaboración CRDT hace que ER Flow sea la primera herramienta de diseño de base de datos que verdaderamente soporta cómo trabajan los equipos modernos: distribuidos, asincronos, y rápidos.