Elegir en la práctica: transporte, fallos y librerías reales

Las cuatro lecciones anteriores dejaron el terreno preparado: dos familias con el mismo poder expresivo, un contrato de red radicalmente distinto en cada una y una técnica intermedia que traslada el punto de equilibrio. Falta lo que decide el resultado de un proyecto, que es traducir todo eso a preguntas que se puedan responder mirando la infraestructura que ya tienes. Qué transporte vas a usar y qué garantiza de verdad. Qué ocurre en tu sistema cuando un mensaje se pierde, cuando llega dos veces o cuando un cliente vuelve después de un mes. Y qué han acabado construyendo las librerías que sostienen sistemas en producción, que casi nunca eligen una familia pura y cuyas decisiones son la mejor guía disponible sobre dónde están los costes reales.

Lo que cada familia le pide a tu transporte

La pregunta operativa no es qué familia prefieres, es qué garantías te da de verdad el canal que vas a usar, porque la diferencia entre las dos familias es exactamente el conjunto de garantías que tendrás que construir tú si el canal no las trae. Y conviene mirar el canal con desconfianza: casi todos los transportes ofrecen menos de lo que su documentación sugiere en cuanto se introduce una reconexión.

Un canal de difusión entre pestañas del mismo navegador entrega en orden a quien está escuchando y no entrega nada a quien no lo estaba, de modo que una pestaña que se abre tarde se ha perdido todo lo anterior sin enterarse. Un socket persistente entrega en orden mientras dura la conexión y no dice nada sobre lo ocurrido durante el corte. Una cola de mensajes del lado servidor suele prometer al menos una vez, que significa duplicados garantizados y orden solo dentro de una partición. Y un almacén de objetos o una carpeta sincronizada no ofrece ni orden ni notificación, solo la posibilidad de leer el último contenido escrito.

Hay una asimetría en esa lista que conviene subrayar. Los transportes ricos —el socket con sesión, la cola ordenada por partición— son los que menos abundan en el escenario que a este track le interesa, que es el de dispositivos de usuario con conectividad intermitente. Los transportes pobres —la carpeta sincronizada, el almacén de objetos, el fichero exportado, el intercambio directo entre dos dispositivos que se encuentran en la misma red local— son exactamente los que un producto local-first acaba necesitando, porque son los únicos que siguen funcionando cuando el servicio central no está disponible. Diseñar para el transporte rico y esperar añadir los pobres después es el orden equivocado.

La regla que se deduce de la tabla es directa y ahorra mucho trabajo cuando se aplica temprano: si el transporte no tiene sesión, no elijas operaciones. Todo lo que una familia basada en operaciones necesita —fiabilidad, deduplicación, orden causal, recuperación tras hueco— es un sistema con estado por cada par de participantes, y montarlo encima de un canal sin sesión significa reimplementar entero un protocolo de transporte fiable en la capa de aplicación. En cambio, un tipo delta sobre un almacén de objetos se escribe en una tarde: cada réplica sube sus fragmentos, cada réplica lee los de los demás y los mezcla, y no hay más protocolo que ese.

Los cuatro fallos y qué hace cada familia con ellos

Conviene tener el cuadro memorizado porque es el que se usa en las revisiones de diseño. Ante pérdida, un sistema de estado o delta se cura solo: el emisor sigue teniendo la información y el siguiente envío la incluye, sin código de recuperación. Un sistema de operaciones no se cura: la operación perdida hay que retransmitirla, lo que exige conservarla y saber que falta, y si se perdió definitivamente, todas las que dependen de ella quedan retenidas para siempre.

// Un canal adversario de veinte lineas vale mas que cualquier diagrama
function canalHostil({ perdida = 0.1, duplicado = 0.1, retraso = 500 }) {
  return (mensaje, entregar) => {
    if (Math.random() < perdida) return;              // se pierde y nadie avisa
    const veces = Math.random() < duplicado ? 2 : 1;  // duplicado silencioso
    for (let i = 0; i < veces; i++) {
      setTimeout(() => entregar(mensaje), Math.random() * retraso); // reordena
    }
  };
}

Ante duplicación, estado y delta no hacen nada porque la idempotencia lo absorbe. Operaciones necesita recordar identificadores ya aplicados, y esa memoria crece con la actividad y hay que podarla con cuidado, porque podar demasiado pronto reabre la puerta al duplicado tardío.

Ante reordenación, estado y delta son indiferentes entre pares distintos y solo exigen que el tramo de un mismo emisor no tenga huecos. Operaciones exige, para todo par de operaciones que no conmute, un orden compatible con la causalidad, lo que implica búfer, resúmenes causales viajando con cada mensaje y una condición de entrega que hay que evaluar en cada recepción.

Ante reconexión tardía, que es el caso que más incidentes produce, estado y delta tienen una respuesta uniforme: enviar el estado completo, que siempre es válido. Operaciones necesita decidir si retransmite un tramo del registro, si compacta, o si abandona el registro y transfiere estado, que es admitir que hace falta la otra familia para el camino de reparación.

Conviene añadir un quinto escenario que no es un fallo del canal y que produce tantos incidentes como los cuatro anteriores juntos: la restauración desde una copia antigua. Un usuario reinstala la aplicación desde una copia de seguridad de hace tres meses, o un administrador restaura un volumen. En la familia de estado y en la delta eso es indistinguible de una réplica que llevaba tres meses sin conectarse, y la mezcla lo resuelve sin código nuevo. En la familia de operaciones es un caso genuinamente distinto, porque la réplica restaurada tiene una cola de salida y una tabla de vistos que ya no se corresponden con lo que el resto del sistema cree que ella sabe, y la reconciliación de esas dos tablas es un procedimiento que hay que escribir, probar y mantener.

flowchart TD
F[fallo del canal] --> P[perdida]
F --> D[duplicado]
F --> R[reordenacion]
F --> T[reconexion tardia]
P --> E1[estado y delta se curan solos]
D --> E2[la idempotencia lo absorbe]
R --> E3[basta tramo sin huecos por emisor]
T --> E4[enviar el estado completo]
P --> O1[operaciones exigen retransmision]
D --> O2[operaciones exigen deduplicar]
R --> O3[operaciones exigen bufer causal]
T --> O4[operaciones acaban transfiriendo estado]
style E1 fill:#a6e3a1,color:#11111b
style E2 fill:#a6e3a1,color:#11111b
style E3 fill:#a6e3a1,color:#11111b
style E4 fill:#a6e3a1,color:#11111b
style O1 fill:#f38ba8,color:#11111b
style O2 fill:#f38ba8,color:#11111b
style O3 fill:#f38ba8,color:#11111b
style O4 fill:#f38ba8,color:#11111b

Qué han construido de verdad las librerías

Lo más instructivo del panorama actual es que casi ninguna implementación seria es una familia pura, y las desviaciones se parecen mucho entre sí. Yjs modela internamente el documento como una estructura de operaciones con identidad por cliente y contador, pero lo que viaja por el cable no es una operación suelta: es un bloque binario producido por encodeStateAsUpdate a partir del vector de estado del otro lado, es decir, exactamente el conjunto de lo que le falta. El protocolo de sincronización tiene dos pasos —te mando mi vector de estado, me mandas lo que me falta— y el resultado es idempotente y mezclable, hasta el punto de que dos actualizaciones se pueden combinar entre sí antes de aplicarlas. Es un motor de operaciones con un cable que se comporta como un delta.

Automerge toma el camino explícito del registro: cada cambio es un bloque inmutable identificado por su hash y con referencias a los hashes de sus predecesores, con lo que el historial es un grafo dirigido acíclico igual que el de un sistema de control de versiones. La identificación por contenido convierte la aplicación en idempotente sin tabla de vistos, y los cambios cuyas dependencias aún no han llegado se retienen hasta que llegan. Su protocolo de sincronización negocia con resúmenes probabilísticos qué le falta a cada lado en vez de enumerarlo, y la versión 3.0 publicada en 2025 redujo el consumo de memoria alrededor de un orden de magnitud reescribiendo esa representación. También ofrece la vía de escape de siempre: serializar el documento entero cuando el intercambio incremental no compensa.

La coincidencia entre ambas es más profunda que la superficie. Las dos identifican cada unidad de cambio de forma estable —por par de cliente y contador en un caso, por hash del contenido en el otro—, y esa identificación estable es lo que convierte la aplicación repetida en inofensiva sin necesidad de una tabla de vistos separada. Las dos retienen lo que llega antes de tiempo en lugar de rechazarlo. Y las dos ofrecen una vía de serialización completa del documento que se usa como reparación y como formato de almacenamiento. Son, en la terminología de este nivel, dos motores de operaciones con un cable de deltas y una salida de emergencia hacia el estado.

// El patron comun, expresado con la interfaz de una libreria tipica
const miVector    = obtenerVectorDeEstado(documentoLocal);
const loQueFalta  = calcularDiferencia(documentoRemoto, miVector); // delta
aplicarActualizacion(documentoLocal, loQueFalta);                  // idempotente

// Y la salida de emergencia, valida siempre
const completo = serializarDocumento(documentoRemoto);
aplicarActualizacion(documentoLocal, completo);

Del lado servidor el patrón es igual de revelador. Los almacenes derivados de Dynamo adoptaron desde el principio la familia basada en estado con vectores de versiones, porque su modelo de comunicación era anti-entropía entre nodos y no había ningún canal ordenado que aprovechar; cuando el tamaño de los objetos empezó a doler, incorporaron deltas en lugar de cambiar de familia. Los sistemas de replicación activa que corren sobre un enlace propio y fiable entre centros de datos, en cambio, sí replican efectos de operaciones, porque el enlace ya les daba las garantías. Y las bibliotecas de datos replicados para sistemas de actores implementan delta como opción de primera clase con difusión por rumores, exactamente el diseño de la cuarta lección.

La conclusión que emerge del recorrido es que la industria convergió a un mismo punto desde los dos extremos. Quien empezó con operaciones acabó añadiendo un mecanismo para pedir y enviar solo lo que falta y un camino de transferencia completa. Quien empezó con estado acabó añadiendo deltas para no mandar el objeto entero. El resultado, en los dos casos, es un sistema que envía fragmentos pequeños durante la operación normal y objetos completos cuando la contabilidad se pierde.

Un criterio de elección que se pueda defender

Con todo lo anterior, la decisión se puede tomar respondiendo cuatro preguntas por escrito, y el orden importa porque cada una descarta opciones antes de que la siguiente se complique. La primera es qué transporte vas a tener de verdad, incluyendo el peor de los que vayas a soportar; si alguno carece de sesión, la respuesta ya está condicionada. La segunda es cuánto pesa tu objeto típico, porque si cabe holgadamente en un mensaje, el estado puro sigue siendo la opción más simple y no hay que justificar nada más.

La tercera es cuánta conmutatividad hay en tu modelo, medida como fracción de pares de operaciones que se pueden aplicar en cualquier orden; si es alta, no vas a necesitar orden causal y el coste de las operaciones cae mucho. Y la cuarta, que suele decidir cuando las tres anteriores empatan, es quién va a operar esto dentro de dos años y qué incidente sabrá diagnosticar: un búfer causal atascado es un diagnóstico que exige entender el modelo, y una réplica que va retrasada por anti-entropía es un diagnóstico que se resuelve mirando un contador.

Una advertencia final que ahorra reescrituras. Sea cual sea la familia elegida, el camino de transferencia completa hay que construirlo desde el primer día y ejecutarlo en cada despliegue, porque es el único mecanismo que repara cualquier estado incoherente y porque es el que nunca se prueba. En los sistemas que fallan de forma memorable, la ruta de reparación existía en el código y no funcionaba, y no funcionaba porque llevaba dieciocho meses sin ejecutarse en ningún entorno real.