Elegir: OT o CRDT, servidor autoritativo o pares

Llegados aquí ya tienes las dos familias en la mano y sabes lo que cada una promete y lo que cada una calla. Falta la parte que decide proyectos, y empieza por corregir una confusión que arruina la mayoría de las discusiones sobre este tema. Se suele plantear la elección como una única pregunta binaria, OT o CRDT, y se le asocia sin pensar una segunda que parece venir incluida, servidor o red entre pares, como si escoger CRDT implicase eliminar el servidor y escoger OT implicase depender de él para siempre. No es así. La forma de fundir cambios y el lugar donde reside la autoridad son ejes ortogonales, y confundirlos lleva a rechazar arquitecturas excelentes por motivos que no existen. El cuadrante más productivo del panorama actual es precisamente el que esa confusión hace invisible: CRDT con servidor autoritativo, es decir, una estructura de datos que sabe fundir sola y un servidor que además persiste, valida, aplica permisos y actúa de testigo para poder recoger basura. Esta lección coloca las opciones en su plano correcto, saca a la luz los costes que las comparativas superficiales omiten y termina proponiendo un método de decisión que sigue funcionando cuando cambien los nombres de las librerías, porque no pregunta por librerías sino por la naturaleza del producto.

Dos ejes, cuatro cuadrantes

El primer eje es el algoritmo de fusión y responde a la pregunta de cómo se reconcilian dos cambios concurrentes: transformando índices contra la historia, que es OT, o dando identidad estable a cada átomo para que la fusión sea una unión, que es CRDT. El segundo eje es la topología de autoridad y responde a una pregunta completamente distinta: quién tiene derecho a decir que no. En un sistema con servidor autoritativo existe un componente que puede rechazar una escritura por permisos, por validación de esquema o por reglas de negocio, y que además conserva la copia canónica. En un sistema entre pares no existe tal componente: cada réplica acepta lo que le llega y la única garantía es que todas acabarán igual.

flowchart TD
A[necesito colaboracion en tiempo real] --> B{debe funcionar sin conexion largo tiempo?}
B -->|si, dias o semanas| C[CRDT]
B -->|no, minutos como mucho| D{alguien debe poder rechazar una escritura?}
D -->|si, permisos y validacion estricta| E[servidor autoritativo]
D -->|no, todos los pares son iguales| C
C --> F{hace falta persistir, validar o compactar?}
F -->|si| G[CRDT con servidor de sincronizacion]
F -->|no| H[CRDT entre pares con rele]
E --> I{quiero orden total y auditoria lineal?}
I -->|si| J[OT con servidor]
I -->|no| G
style G fill:#a6e3a1,color:#11111b
style H fill:#94e2d5,color:#11111b
style J fill:#89b4fa,color:#11111b

La lectura importante del diagrama es que la primera pregunta descarta un eje entero y la segunda descarta el otro, y que hacerlas en ese orden ahorra discusiones inútiles. Si tu producto debe funcionar desconectado durante días, el eje del algoritmo ya está decidido y no hay nada que debatir: OT necesita reconciliar contra una historia y esa reconciliación se degrada con el tiempo de ausencia. Si tu producto exige que un servidor pueda rechazar una escritura porque este usuario no puede editar esta celda, el eje de la topología también está decidido, y da igual qué familia de fusión elijas después. Solo cuando ninguna de las dos preguntas es tajante entra en juego el resto de criterios, y entonces conviene mirar los costes que nadie enseña.

Los costes que no salen en la comparativa

Las tablas comparativas suelen limitarse a la corrección y a la latencia, que son precisamente los ejes en los que ambas familias están resueltas. Los costes que de verdad deciden aparecen después, cuando el producto lleva meses en producción.

// El punto donde los dos ejes se tocan de verdad: rechazar una escritura.
// Con servidor autoritativo esto existe; entre pares, no hay donde ponerlo.
function alRecibirCambio(usuario: Usuario, cambio: Cambio) {
  if (!puedeEditar(usuario, cambio.seccion)) return rechazar(cambio)
  if (!esquema.safeParse(cambio.valor).success) return rechazar(cambio)
  aplicarYDifundir(cambio)          // solo ahora entra en el documento
}

Conviene además situar una tercera categoría que no encaja limpiamente en ninguno de los dos ejes y que domina cada vez más productos: los motores de sincronización. En lugar de sincronizar un documento colaborativo, sincronizan el conjunto de registros que un cliente necesita, aplican los cambios locales al instante y los reconcilian después contra un servidor que sigue siendo la autoridad. Su reconciliación no suele ser ni OT ni un CRDT completo, sino un esquema más modesto de mutaciones con identidad, reintento y reordenación, que resulta suficiente porque su granularidad es el registro y no el carácter. Si tu producto se parece más a un gestor de incidencias que a un editor de texto, ese es probablemente tu cuadrante real, y llegar a él tras haber entendido las dos familias es la única manera de elegirlo por convicción y no por descarte.

Hay además un criterio que pesa más de lo que a un ingeniero le gusta admitir, y es qué se puede comprar hecho. Escribir OT correcto desde cero es un proyecto de meses con riesgo real de incorrección silenciosa, y escribir un CRDT de secuencia competitivo en rendimiento es todavía peor. El ecosistema maduro está hoy claramente del lado de los CRDT —Yjs y su familia de conectores para los editores habituales, Automerge con su modelo de documento y su historial, Loro como alternativa reciente— y del lado de OT sobreviven sobre todo ShareDB y las implementaciones internas de las grandes empresas. Elegir la familia con mejor ecosistema no es pereza: es reconocer que la parte difícil de este problema ya fue resuelta por gente que dedicó años a ella y que tus contraejemplos de TP2 no van a ser mejores que los suyos.

Cuatro preguntas en orden de descarte

Un método de decisión útil no es una lista de criterios, es una secuencia ordenada por capacidad de eliminar alternativas, de modo que las preguntas caras solo se hagan si las baratas no han decidido ya. Estas cuatro, en este orden, resuelven la inmensa mayoría de los casos reales.

• Cuánto tiempo debe funcionar sin conexión. Si la respuesta se mide en días, el eje del algoritmo está decidido y es CRDT. Si se mide en segundos de red inestable, ambas familias sirven y la pregunta no descarta nada.
• Quién debe poder rechazar una escritura. Si existe una sola regla de permisos, validación o negocio que deba imponerse aunque el cliente esté manipulado, necesitas servidor autoritativo. Si no existe ninguna, tienes abierto el cuadrante entre pares y con él el cifrado de extremo a extremo.
• Qué forma tiene el dato. Texto plano, texto enriquecido con atributos, árbol de bloques, lista de registros o campos independientes. Cuanto más estructurado y más propenso a crecer el modelo, más pesa la composicionalidad que la lección anterior atribuyó a los CRDT.
• Qué se puede comprar hecho. Qué editor usas, qué conectores existen para él, quién mantiene la librería y cuántos productos serios dependen de ella. Es la pregunta menos noble y la que más proyectos ha salvado.

Obsérvese que ninguna de las cuatro menciona rendimiento. No es un descuido: en el rango de tamaños en que trabajan casi todos los productos, ambas familias son suficientemente rápidas, y elegir por comparativas de milisegundos es optimizar el eje que no te va a doler mientras se ignoran los tres que sí. El rendimiento entra en la conversación cuando el documento es descomunal o el dispositivo es muy limitado, y entonces se convierte en una restricción dura que hay que medir con tus propios datos y no con los del anuncio de nadie.

Los casos límite que deciden en la práctica

Cuando las cuatro preguntas dejan empate, la decisión suele resolverla uno de estos tres detalles, que comparten la propiedad de parecer secundarios en el diseño y volverse centrales en el mes tres de desarrollo.