MV-Register: conservar los dos valores y decirlo

La segunda salida invierte la pregunta. En vez de fabricar un orden donde no lo hay, el registro multivalor acepta que dos escrituras pueden ser genuinamente incomparables y se limita a conservarlas las dos, dejando que la lectura devuelva un conjunto en lugar de un valor. La consecuencia es más grande de lo que parece y no es de rendimiento: el tipo de la lectura cambia, y ese cambio de tipo se propaga hacia arriba hasta la interfaz, que ya no puede pintar el campo sin haber decidido antes qué hace cuando hay dos. Esa incomodidad es la característica, no el defecto. Un sistema que devuelve un conjunto está diciendo la verdad sobre su estado; uno que devuelve un valor está afirmando que sabe cuál era el correcto, y en el caso concurrente esa afirmación es falsa. Todo lo demás de esta lección —vectores, dominación, poda— es la maquinaria que hace esa honestidad barata.

La anticadena: la lectura deja de devolver un valor

El estado de un registro multivalor no es un valor con metadatos, sino un conjunto de pares formados por un valor y su contexto causal. La invariante que lo define es que ese conjunto es una anticadena: ningún elemento domina causalmente a otro. En cuanto una escritura domina a otra, la dominada deja de tener sentido y se descarta, porque quien escribió la nueva ya había visto la vieja y su intención era sustituirla. Solo sobreviven juntas las escrituras que se hicieron sin conocerse.

De ahí sale la propiedad que hace la estructura tolerable en la práctica y que casi nadie espera al conocerla: el conjunto no acumula historia. Cada asignación local colapsa a un único elemento todo lo que la réplica había visto hasta ese momento, así que el tamaño del conjunto no mide cuántas veces se ha editado el campo sino cuántas ramas de edición concurrente siguen abiertas ahora mismo. En una aplicación normal ese número es uno casi todo el tiempo, dos ocasionalmente y tres muy rara vez.

flowchart TB
I[valor inicial visto por ambas replicas] --> A[replica A asigna rojo]
I --> B[replica B asigna azul]
A --> F[fusion en la que ninguno domina al otro]
B --> F
F --> S[lectura devuelve rojo y azul]
S --> C[alguien asigna verde tras verlos]
C --> U[la anticadena vuelve a tener un solo elemento]
style F fill:#f9e2af,color:#11111b
style U fill:#a6e3a1,color:#11111b

La implementación

Todo se apoya en el vector de versiones del nivel veintidós y en su relación de dominación. Conviene escribir primero esas dos piezas por separado, porque son las que deciden la corrección y las que hay que probar a fondo.

// Vector de versiones: un contador por replica, ausente equivale a cero
function unionVV(a, b) {
  const r = { ...a };
  for (const k of Object.keys(b)) r[k] = Math.max(r[k] ?? 0, b[k]);
  return r;
}

function dominaOigual(a, b) {
  return Object.keys(b).every((k) => (a[k] ?? 0) >= b[k]);
}

const dominaEstricto = (a, b) => dominaOigual(a, b) && !dominaOigual(b, a);
const concurrentes = (a, b) => !dominaOigual(a, b) && !dominaOigual(b, a);

El registro es una lista de entradas, cada una con su valor y su vector. La asignación es la operación interesante: no añade una entrada, las sustituye a todas, porque quien escribe ha visto todo lo que su réplica tenía y su vector domina a todos los que había.

function crearMV() {
  return { entradas: [] };
}

function asignarMV(reg, replica, valor) {
  const base = reg.entradas.reduce((acc, e) => unionVV(acc, e.vv), {});
  const vv = { ...base, [replica]: (base[replica] ?? 0) + 1 };
  return { entradas: [{ valor, vv }] }; // colapsa toda la anticadena vista
}

function fusionarMV(a, b) {
  const todas = [...a.entradas, ...b.entradas];
  const vivas = todas.filter((e) => !todas.some((o) => dominaEstricto(o.vv, e.vv)));
  const unicas = new Map();
  for (const e of vivas) unicas.set(JSON.stringify(e.vv), e);
  return { entradas: [...unicas.values()] };
}

La deduplicación por vector no es una optimización, es lo que hace idempotente la fusión: dos copias de la misma entrada tienen vectores idénticos, ninguna domina estrictamente a la otra y ambas sobrevivirían al filtro. Con el mapa por vector serializado, fusionar un estado consigo mismo devuelve exactamente el mismo estado, que es la tercera ley del semirretículo.

La lectura merece dos cuidados que se olvidan siempre. El primero es el orden: la lista tiene que salir ordenada de forma determinista, porque si no dos réplicas convergentes pintarán el conflicto en distinto orden y el usuario creerá que no han convergido. El segundo es la deduplicación por valor: dos personas pueden escribir concurrentemente exactamente lo mismo, y en ese caso hay dos entradas y un solo valor, así que enseñar dos opciones idénticas es un conflicto inventado.

function leerMV(reg) {
  const clave = (e) => JSON.stringify(e.vv);
  const orden = [...reg.entradas].sort((x, y) => (clave(x) < clave(y) ? -1 : 1));
  return [...new Set(orden.map((e) => e.valor))]; // determinista y sin duplicados
}

Lo que crece, y lo que no

Hay que separar dos crecimientos distintos que se confunden constantemente. El primero es el número de entradas, y ya vimos que está acotado por la anchura de la concurrencia actual, no por la historia: una sola asignación posterior a haberlas visto todas devuelve el conjunto a un elemento. El segundo es el tamaño de cada vector de versiones, que crece con el número de réplicas que han escrito alguna vez ese campo y que no se reduce solo. En un producto con muchos dispositivos por usuario, ese segundo coste es el que duele, y es exactamente el que el nivel veintidós ya te enseñó a pagar y a podar.

Existe además un modo de fallo con nombre propio, la explosión de hermanos, que se atribuye a la estructura y en realidad es siempre un fallo del cliente. Ocurre cuando alguien lee el registro, decide un valor y escribe sin devolver el contexto causal que leyó. Al no dominar a nada, su escritura se añade a la anticadena en vez de colapsarla, y el conjunto crece sin freno escritura tras escritura. Es el mismo error de la lección anterior con otra cara: allí se olvidaba alimentar el reloj al recibir, aquí se olvida devolver el vector al escribir.

// INCORRECTO: la resolucion no domina a lo que resolvio
function resolverMal(reg, replica, elegido) {
  return { entradas: [{ valor: elegido, vv: { [replica]: 1 } }] };
}

// CORRECTO: resolver es asignar habiendo visto la anticadena entera
function resolver(reg, replica, elegido) {
  return asignarMV(reg, replica, elegido); // el vector base domina a todos los hermanos
}

Devolver un conjunto es una decisión de interfaz

El registro multivalor no resuelve el conflicto: lo hace representable. Quien lo resuelve es la capa de arriba, y ahí es donde la construcción se gana o se pierde por completo. Hay tres maneras de neutralizarla sin darse cuenta, y las tres son habituales. La primera es que la interfaz tome siempre el primer elemento de la lista: eso es un registro de última escritura con más metadatos, más latencia y ninguna ventaja. La segunda es tomar el mayor por sello si además se guardó uno: lo mismo, con la excusa cronológica de vuelta. La tercera, más sutil, es mostrar el conflicto en un lugar que nadie mira, con lo cual el usuario resuelve sin saberlo la próxima vez que edite el campo por otro motivo.

La alternativa exige poco código y bastante criterio de producto. Para un campo enumerado, mostrar las dos opciones y pedir que se elija es barato y honesto. Para dos textos, ofrecer los dos y permitir quedarse con uno o combinarlos a mano funciona. Para valores numéricos con semántica de acumulación, muchas veces la respuesta correcta no es elegir sino aplicar una función de resolución determinista —el máximo, la suma— y en ese momento lo que estás descubriendo es que ese campo no era un registro.