Basados en operaciones: enviar solo lo que se hizo

La otra manera de construir un tipo replicado que converge invierte el reparto de responsabilidades. En lugar de mandar el objeto y confiar en un álgebra que absorbe cualquier maltrato del canal, se manda únicamente lo que se hizo —insertó esto aquí, incrementó en tres, quitó esta etiqueta— y se confía en que el canal entregue cada mensaje a todo el mundo una vez y solo una. El resultado es que el tráfico deja de depender del tamaño del documento y pasa a depender del tamaño de la edición, que es lo que la intuición esperaba desde el principio. El precio no desaparece: se muda. Todo lo que la familia anterior resolvía con tres leyes algebraicas hay que resolverlo ahora en la capa de transporte, y esa capa es un sistema entero con su propio estado, sus propios fallos y su propia complejidad.

Preparar y efectuar: por qué son dos funciones distintas

Una operación en esta familia nunca es lo que el usuario pulsó. Es lo que el usuario pulsó traducido a una forma que cualquier réplica pueda aplicar sin ambigüedad, y esa traducción ocurre una sola vez, en la réplica donde se originó. La fase de preparación lee el estado local, resuelve todo lo que dependa de él y produce un mensaje autocontenido. La fase de efecto aplica ese mensaje y no puede consultar nada que pueda diferir entre réplicas: ni un identificador aleatorio nuevo, ni el reloj, ni el tamaño actual de una lista.

La razón es que el efecto se ejecuta en todas partes, incluida la réplica de origen, y debe producir lo mismo en todas. Si la preparación de una inserción resuelve la posición como un índice numérico, dos réplicas que hayan aplicado operaciones distintas antes interpretarán ese índice sobre listas de longitudes distintas y divergirán. Por eso la preparación traduce la posición a algo estable: el identificador del elemento anterior, un identificador de la propia inserción, y nada más.

// Preparar mira el estado local; efectuar no puede mirar nada local
function prepararInsertar(estado, indice, texto, replica) {
  const anterior = estado.orden[indice - 1]?.id ?? null; // se resuelve aqui
  return {
    tipo: "insertar",
    id: `${replica}:${estado.reloj + 1}`,               // identidad estable
    anterior,
    texto,
  };
}

function efectuar(estado, op) {
  if (estado.vistas.has(op.id)) return estado; // defensa, no garantia
  const pos = op.anterior === null ? 0 : indiceDe(estado, op.anterior) + 1;
  return insertarEn(estado, pos, op);
}

La prohibición de consultar el entorno durante el efecto es más amplia de lo que parece y conviene enumerarla, porque cada uno de sus incumplimientos produce una divergencia distinta y todos son fáciles de cometer sin darse cuenta. No se puede leer el reloj, porque cada réplica lo aplica en un instante distinto. No se puede generar un identificador aleatorio, porque cada réplica generaría uno diferente. No se puede consultar una configuración local, porque puede variar entre dispositivos. No se puede depender del tamaño ni del contenido actual de la estructura, porque el efecto se aplica sobre estados intermedios distintos en cada réplica. Y no se puede consultar la red, ni siquiera para validar, porque la respuesta puede diferir. Todo lo que sea variable se resuelve en la preparación y viaja dentro del mensaje.

La comprobación de la primera línea del efecto merece un comentario, porque induce a error con facilidad. Guardar los identificadores ya vistos protege frente a una entrega duplicada, y muchas implementaciones lo hacen. Pero eso no convierte a la familia en tolerante a duplicados: convierte a esa operación concreta en idempotente, y el conjunto de identificadores vistos es estado adicional que crece sin límite y que hay que podar, con el mismo problema de fondo que las lápidas. La garantía sigue estando en el canal; lo único que ha cambiado es dónde se paga.

Lo que el canal tiene que garantizar de verdad

El contrato mínimo de esta familia tiene tres cláusulas y conviene enunciarlas por separado porque no todas son igual de caras. La primera es entrega fiable: toda operación emitida acaba llegando a toda réplica, lo que exige acuses, reintentos y un registro persistente de lo que aún no se ha confirmado. La segunda es entrega exactamente una vez, que en realidad nadie implementa como tal: lo que se implementa es al menos una vez más deduplicación en el receptor, y ese segundo componente es memoria que crece. La tercera es la que separa a los diseños fáciles de los difíciles.

Esa tercera cláusula es el orden, y su intensidad depende enteramente del álgebra de tus operaciones. Si todas las operaciones conmutan entre sí sin excepción, no hace falta ningún orden: pueden aplicarse en cualquiera y el resultado es el mismo. Si existen pares que no conmutan, hace falta que las réplicas los apliquen en un orden compatible, y en la práctica eso se resuelve exigiendo difusión causal fiable: una operación no se entrega hasta que se han entregado todas las que su emisor había visto al prepararla.

flowchart LR
P[preparar en la replica de origen] --> E[emitir el mensaje]
E --> C[canal fiable y sin duplicados]
C --> B[bufer de reordenacion causal]
B --> F[efectuar en cada replica]
F --> G[estado convergente]
style C fill:#f38ba8,color:#11111b
style B fill:#f9e2af,color:#11111b
style G fill:#a6e3a1,color:#11111b

Merece la pena insistir en la segunda cláusula porque se enuncia mal casi siempre. La entrega exactamente una vez no existe como propiedad de un canal, y no por falta de ingenio: un emisor que no recibe confirmación no puede distinguir entre un mensaje perdido y una confirmación perdida, de modo que solo puede elegir entre reintentar, que produce duplicados, y no reintentar, que produce pérdidas. Lo que sí existe es al menos una vez en el canal más deduplicación o idempotencia en el receptor, y esa segunda mitad es responsabilidad de tu código y no del transporte que contrataste. Todo diseño que dé por resuelta esta cláusula porque la documentación de una cola la promete está apoyándose en una promesa que no se puede cumplir.

flowchart LR
A[al menos una vez en el canal] --> B[deduplicacion en el receptor]
B --> C[efecto aplicado una sola vez]
D[como mucho una vez en el canal] --> E[perdida silenciosa]
style C fill:#a6e3a1,color:#11111b
style E fill:#f38ba8,color:#11111b

La difusión causal no es magia ni una biblioteca que se importa: es un componente con estado. Cada mensaje viaja acompañado de un resumen de lo que su emisor había visto —un vector de versiones o el conjunto de dependencias directas—, y el receptor lo retiene en un búfer hasta que ese resumen queda cubierto por lo que ya aplicó. Ese búfer es memoria que puede crecer sin cota si un emisor lento deja huecos, y es una fuente inagotable de fallos difíciles: un mensaje que nunca llega bloquea indefinidamente a todos los que dependen de él, y el sistema no se cae, simplemente deja de progresar en silencio.

Lo que se ahorra y cómo medirlo

El beneficio es nítido y se puede cuantificar sin ambigüedad. El mensaje mide lo que mide la intención, de modo que insertar un carácter cuesta unas decenas de bytes con independencia de que el documento tenga diez kilobytes o cuarenta megabytes. El coste de aplicar es igualmente local: efectuar una inserción toca la región afectada y no recorre la estructura completa. En una sesión de edición colaborativa con varias personas escribiendo a la vez, la diferencia entre las dos familias no es de un factor pequeño, es de varios órdenes de magnitud.

Conviene cuantificarlo con un ejemplo concreto para tener la escala presente. Un documento de texto colaborativo de dos megabytes editado por tres personas durante una hora a un ritmo modesto de cien pulsaciones por minuto genera del orden de dieciocho mil operaciones. Bajo la familia de operaciones eso son unos cuantos cientos de kilobytes de tráfico total; bajo la familia de estado sin deltas, con una sincronización por segundo, son varios gigabytes por participante. La diferencia no admite discusión y explica por qué la edición colaborativa en tiempo real nació en el territorio de las operaciones y tardó en salir de él.

Hay un tercer beneficio menos evidente y que en varios dominios pesa más que el tráfico: la operación conserva la intención, mientras que el estado la borra. Cuando una réplica recibe un estado con un contador a siete, no sabe si alguien sumó siete o si alguien sumó diez y otro restó tres, y esa información ya no existe en ninguna parte. Cuando recibe la operación de incrementar en tres, tiene delante lo que el usuario quiso. Para auditoría, para deshacer selectivo, para explicarle a alguien por qué un valor cambió y para depurar un incidente, esa diferencia es la que decide si el problema es investigable.

El coste que no aparece en las cuentas de tráfico

El primer coste oculto es el del registro persistente. Una operación no puede considerarse emitida hasta que está a salvo en disco, porque si la aplicación se cierra entre el efecto local y el envío, la réplica de origen tendrá un estado que ninguna otra podrá alcanzar jamás. Eso significa que cada edición implica una escritura durable antes de la confirmación visual, o bien asumir explícitamente una ventana de pérdida y decir en voz alta cuánto dura. La cola de salida deja de ser un detalle del transporte y pasa a ser estado de primera clase, que hay que versionar, migrar entre versiones del esquema y compactar como cualquier otro.

El segundo es la memoria de entrega. La deduplicación por identificador solo es correcta si el identificador se recuerda al menos tanto como el canal puede retrasar un duplicado, y como ningún canal real acota ese retraso, en la práctica se recuerda todo o se acota con un corte causal: puedo olvidar los identificadores que sé que toda réplica ya aplicó. Calcular ese conjunto exige saber quién existe y hasta dónde ha llegado cada uno, es decir, reintroduce una tabla global que la familia anterior no necesitaba.

// Tres estructuras que no existian en la familia basada en estado
const colaSalida  = [];          // durable: operaciones emitidas sin confirmar
const yaAplicadas = new Set();   // crece con la actividad, poda con corte causal
const buferCausal = new Map();   // operaciones retenidas por dependencias ausentes

function recibir(op) {
  if (yaAplicadas.has(op.id)) return;
  if (!dependenciasCubiertas(op)) { buferCausal.set(op.id, op); return; }
  estado = efectuar(estado, op);
  yaAplicadas.add(op.id);
  desbloquearDependientes(); // puede liberar en cascada
}

El tercero es el más difícil de presupuestar porque no es una estructura sino una obligación permanente: alguien tiene que vigilar el búfer causal. Un búfer que crece es la señal de que faltan operaciones, y esa señal debe llegar a alguien antes de que el usuario note que sus cambios no aparecen. Un sistema de esta familia sin métrica del tamaño del búfer y de la antigüedad de la operación retenida más vieja es un sistema que descubrirá sus incidentes por el canal de soporte.