CRDT delta: enviar el trozo que cambió sin perder la mezcla

La familia basada en estado tenía un contrato de red imbatible y una factura de ancho de banda que la hacía inviable para cualquier documento que no cupiese en un mensaje. Durante años esa tensión se dio por irreductible y se tomó como el argumento decisivo a favor de las operaciones. La salida llegó al reformular la actualización local: en lugar de una función que lleva un estado a otro estado, se define una función que produce el fragmento de estado que la actualización aporta, con la condición de que ese fragmento sea, en sí mismo, un elemento legítimo del retículo. Al serlo, se puede enviar en lugar del objeto entero y el receptor lo trata con la misma mezcla de siempre, sin distinguirlo de un estado completo. Es una idea pequeña con consecuencias desproporcionadas, y es la que hizo prácticos a los tipos basados en estado.

El delta-mutador y la condición que lo define

Un delta-mutador asociado a una actualización es una función que, dado el estado actual, devuelve un fragmento tal que mezclarlo con ese estado produce exactamente lo mismo que habría producido la actualización original. Escrito como identidad: mezclar(estado, delta(estado)) debe ser igual a actualizar(estado). Nada más se exige, y de esa única condición se sigue todo el aparato, porque el fragmento devuelto pertenece al mismo conjunto de estados y por tanto es mezclable con cualquier otro elemento, en cualquier orden y cuantas veces haga falta.

// El delta no es un parche: es un estado minusculo del mismo tipo
function deltaIncrementar(estado, replica, n = 1) {
  return { [replica]: (estado[replica] ?? 0) + n }; // un solo componente
}

const local  = mezclar(estadoActual, deltaIncrementar(estadoActual, "A"));
const remoto = mezclar(estadoDelPar, deltaIncrementar(estadoActual, "A"));
// La misma funcion de mezcla sirve para el fragmento y para el estado entero

Repara en el detalle que hace que esto funcione y que distingue un delta de un parche convencional. Un parche describe una transformación y depende del contexto sobre el que se aplica: aplicarlo dos veces daña, aplicarlo fuera de orden daña, aplicarlo sobre una base distinta falla. Un delta no describe una transformación, describe un estado, y por eso hereda las tres leyes sin discusión. Mezclarlo dos veces es inofensivo por idempotencia. Mezclarlo con deltas de otras réplicas en cualquier orden da lo mismo por conmutatividad y asociatividad. Y perderlo solo retrasa la convergencia, porque el estado del emisor sigue conteniéndolo.

Conviene también notar el valor concreto que devuelve el ejemplo: es el contador acumulado de la réplica, no el incremento de uno. Esa elección no es cosmética. Si el delta contuviese el incremento aislado, la mezcla por máximo lo interpretaría mal y la duplicación dejaría de ser inocua. El delta tiene que estar expresado en el mismo lenguaje que el estado, y ese requisito es lo que a veces obliga a rediseñar la representación antes de poder deltificar un tipo.

El ejercicio se repite con cada estructura y en la mayoría sale sin esfuerzo. En un conjunto que solo crece, el delta de un alta es el conjunto de un elemento. En un mapa de registros con marca de versión, el delta de una escritura es el mapa con esa única clave. En un máximo, el delta es el propio valor. La regla general que emerge es que el delta de una actualización es la proyección del estado resultante sobre la parte que la actualización tocó, y por eso siempre es un elemento legítimo: es un trozo del retículo, no una descripción de cómo llegar hasta él.

// Un conjunto que solo crece: el delta de un alta es un conjunto de un elemento
const mezclarConjunto = (a, b) => new Set([...a, ...b]);
const deltaAnadir = (_estado, elemento) => new Set([elemento]);

// Un registro por clave: el delta de una escritura toca una sola clave
const deltaEscribir = (estado, clave, valor, replica) => ({
  [clave]: { valor, version: (estado[clave]?.version ?? 0) + 1, replica },
});

Delta-grupos: acumular localmente y enviar una vez

Enviar un mensaje por cada pulsación de tecla es correcto y es un desastre operativo. La solución no requiere teoría nueva: como la mezcla es asociativa, los deltas producidos entre dos envíos pueden mezclarse entre sí en local para formar un único fragmento acumulado —un delta-grupo— cuyo efecto es idéntico al de haberlos enviado uno a uno. La emisión pasa a ser periódica, el número de mensajes deja de depender del ritmo de tecleo y el tamaño del grupo queda acotado por lo que se haya tocado en el intervalo, no por el documento entero.

// Acumular deltas en local y vaciar por tiempo o por tamano
let pendiente = {};

function aplicarLocal(d) {
  estado    = mezclar(estado, d);
  pendiente = mezclar(pendiente, d); // la asociatividad lo autoriza
}

function vaciar(enviar) {
  if (Object.keys(pendiente).length === 0) return;
  enviar(pendiente);
  pendiente = {}; // solo tras confirmar; si no, se reintenta sin dano
}

flowchart LR
U1[edicion] --> D1[delta 1]
U2[edicion] --> D2[delta 2]
U3[edicion] --> D3[delta 3]
D1 --> G[delta grupo acumulado]
D2 --> G
D3 --> G
G --> R[mezcla en la replica remota]
R --> S[mismo resultado que enviarlos sueltos]
style G fill:#a6e3a1,color:#11111b
style S fill:#89b4fa,color:#11111b

La línea del vaciado que devuelve el pendiente a vacío solo tras confirmar el envío merece atención porque es donde vive la tolerancia a fallos de todo el esquema. Si el envío falla, el grupo sigue ahí y se reintenta; si el envío llegó pero la confirmación se perdió, el reintento entrega un duplicado que la idempotencia absorbe sin consecuencias. Es el mismo comportamiento que ofrecería una cola con reintentos, obtenido sin cola, sin números de secuencia y sin protocolo, únicamente porque el objeto que viaja es un elemento del retículo.

El intervalo causal: la condición que no se puede saltar

Hasta aquí la técnica parece gratuita, y hay exactamente un lugar donde no lo es. Para tipos cuyo delta es independiente del contexto —contadores, conjuntos que solo crecen, máximos, registros de última escritura— basta con mezclar lo que llegue. Pero para tipos donde una operación depende causalmente de otra, mezclar un delta sin haber mezclado antes aquello de lo que depende puede producir un estado que ninguna secuencia legítima habría alcanzado. El caso clásico es el conjunto con borrados: un delta que representa el borrado de un elemento debe llegar acompañado del conocimiento de las altas que borra, o el receptor no sabrá que eran las mismas.

La condición correcta se enuncia con precisión: la secuencia de deltas que una réplica recibe de un par debe formar un intervalo causalmente consistente, es decir, un tramo contiguo de la historia de ese par sin huecos. No hace falta orden global, ni difusión causal entre todas las réplicas: basta con que cada par a par no se salte fragmentos. Eso se consigue numerando los deltas por emisor y llevando la cuenta de hasta dónde ha reconocido cada destinatario, que es una tabla pequeña y local.

// Numeracion por emisor y tabla de reconocidos: toda la contabilidad necesaria
let siguiente = 0;
const almacen  = new Map();  // numero de secuencia a delta
const acuse    = new Map();  // destinatario a ultimo numero reconocido

function emitir(d) {
  almacen.set(siguiente++, d);
}

function tramoPara(destino) {
  const desde = (acuse.get(destino) ?? -1) + 1;
  if (!almacen.has(desde)) return { tipo: "estado", cuerpo: estado }; // hueco: mandar todo
  const trozos = [...almacen].filter(([n]) => n >= desde).map(([, d]) => d);
  return { tipo: "tramo", desde, cuerpo: trozos.reduce(mezclar, {}) };
}

Observa la rama que devuelve el estado completo cuando el delta más antiguo que el destinatario necesita ya fue descartado del almacén. No es un caso de error ni una degradación: es la política de retención funcionando como se diseñó. Guardar deltas indefinidamente para un destinatario que puede no volver nunca sería la peor decisión posible, y la existencia de una salida siempre correcta permite fijar la retención por criterios de espacio y no por miedo.

Lo que se conserva y lo que sigue costando

El balance final explica por qué esta idea reordenó el área. Se conserva el contrato de red barato en todo lo esencial: los duplicados siguen siendo inocuos, el orden entre pares distintos sigue siendo irrelevante y no hace falta difusión causal global. Se conserva la demostración de convergencia, que es la misma de siempre porque el objeto que viaja es del mismo tipo. Y se gana lo único que faltaba: el mensaje mide lo que mide la edición, con lo que desaparece el argumento que hacía inviable a la familia para documentos grandes.

Lo que se paga es contabilidad, y conviene tenerla presente antes de darla por gratuita. Hay que numerar los deltas por emisor y conservarlos hasta que todos los destinatarios conocidos los hayan reconocido, lo que implica un búfer de salida con política de retención y una decisión sobre qué hacer con un destinatario que lleva semanas sin aparecer. Hay que llevar la tabla de reconocimientos, que crece con el número de pares. Y hay que decidir el umbral a partir del cual conviene mandar el estado completo en vez de un tramo largo, porque llega un punto en que el tramo pesa más que el objeto.