LWW-Register: comprar un orden total y pagarlo con datos

La primera salida del problema del registro consiste en negarse a aceptar que existan escrituras incomparables: si la especificación secuencial necesita una última, se fabrica una. Se adjunta a cada asignación un sello, se declara que la mayor gana y el tipo pasa a tener supremo. Es una construcción de ocho líneas, converge sin discusión, cuesta un campo por dato y no obliga a pensar en el modelo, y por eso es la política que trae de fábrica prácticamente cualquier motor de sincronización que instales. Lo que casi nadie mira es de dónde sale el sello, y ahí está todo. Con el reloj del sistema, el registro elige al dispositivo peor calibrado y lo llama último. Con un reloj lógico de los niveles veintiuno y veintidós, elige de una manera defendible y reproducible. La diferencia entre las dos versiones es de treinta líneas de código y de una categoría entera de incidencias que nunca se cierran.

La construcción, y el reloj que la sostiene

El sello no puede ser la hora del sistema, y la lección tres del nivel veintitrés dejó claro por qué: la deriva de un reloj es un sesgo persistente, no un ruido, así que un dispositivo adelantado gana estructuralmente todas las disputas y uno atrasado no gana ninguna. El reloj híbrido del nivel veintidós resuelve la parte que se puede resolver: nunca retrocede, respeta la causalidad y se mantiene cerca de la hora real. Empecemos por él, porque el registro es un envoltorio fino sobre esa pieza.

// Reloj hibrido del nivel 22: valor fisico anclado mas contador de desempate
function crearReloj(id, ahora = () => Date.now()) {
  return { id, l: 0, c: 0, ahora };
}

function sellar(r) {
  const previo = r.l;
  r.l = Math.max(previo, r.ahora());
  r.c = r.l === previo ? r.c + 1 : 0;
  return { l: r.l, c: r.c, id: r.id };
}

function observar(r, s) {
  const previo = r.l;
  r.l = Math.max(previo, s.l, r.ahora());
  if (r.l === previo && r.l === s.l) r.c = Math.max(r.c, s.c) + 1;
  else if (r.l === previo) r.c = r.c + 1;
  else if (r.l === s.l) r.c = s.c + 1;
  else r.c = 0;
}

// Orden total estricto: fisico, contador y por ultimo identidad
function menor(x, y) {
  if (x.l !== y.l) return x.l < y.l;
  if (x.c !== y.c) return x.c < y.c;
  return x.id < y.id;
}

Con eso el registro es casi anecdótico, y esa brevedad es exactamente su atractivo comercial.

const crearLWW = (valor, sello) => ({ valor, sello });

function asignarLWW(reloj, valor) {
  return { valor, sello: sellar(reloj) };
}

// Conmutativa, asociativa e idempotente porque el orden es total y estricto
function fusionarLWW(a, b) {
  return menor(a.sello, b.sello) ? b : a;
}

const leerLWW = (reg) => reg.valor;

Conviene comprobar las tres leyes en lugar de creerlas. La conmutatividad sale de que menor es un orden total: para cualquier par distinto, uno de los dos es estrictamente menor, y la respuesta no depende de la posición del argumento. La asociatividad sale de que quedarse con el mayor de tres es independiente del paréntesis. Y la idempotencia sale de que menor es estricto: comparado consigo mismo devuelve falso y la fusión conserva el primero, que es el mismo objeto. Si alguien relaja menor a un menor o igual, la idempotencia se mantiene por casualidad y la conmutatividad se rompe, que es el fallo más habitual al escribir esta función a mano.

El desempate y el error que arruina la construcción

El tercer criterio, la identidad de la réplica, no es un adorno defensivo: es obligatorio. Dos réplicas pueden producir el mismo par físico y lógico —es raro pero no imposible, y con relojes de baja resolución deja de ser raro—, y si dos sellos empatan, cada réplica elegiría el suyo y la divergencia sería permanente. Cualquier criterio determinista y consistente sirve, porque su arbitrariedad no añade injusticia: solo la vuelve reproducible. Lo importante es que todas las réplicas apliquen el mismo, y por eso el identificador tiene que viajar dentro del sello y no derivarse del contexto de quien fusiona.

Ahora el error que de verdad hace perder datos en implementaciones que ya usan reloj lógico, y que se comete casi siempre. El reloj tiene dos entradas: sellar, para escribir, y observar, para incorporar lo que llega. Si la réplica fusiona un estado remoto sin llamar a observar con su sello, su reloj no se entera de nada, y la siguiente escritura local se sella con un valor que puede ser menor que el del cambio que el usuario acaba de leer en pantalla. El resultado es una corrección que nace derrotada: el usuario ve el valor ajeno, escribe encima, ve su cambio aplicado en local y lo ve desaparecer en la siguiente sincronización, una y otra vez.

// INCORRECTO: el reloj local no ve el sello remoto
function aplicarRemotoMal(estado, remoto) {
  return fusionarLWW(estado, remoto);
}

// CORRECTO: fusionar es tambien observar
function aplicarRemoto(estado, remoto, reloj) {
  observar(reloj, remoto.sello);
  return fusionarLWW(estado, remoto);
}

flowchart TB
R[estado remoto con su sello] --> O[el reloj observa y adopta el maximo]
O --> F[la fusion se queda con el sello mayor]
F --> E[estado local convergido]
E --> A[siguiente asignacion local]
A --> S[el sello nuevo supera a todo lo visto]
S --> G[la correccion del usuario gana]
style O fill:#a6e3a1,color:#11111b
style G fill:#a6e3a1,color:#11111b

Qué pierde, exactamente

La construcción es correcta y aun así destruye trabajo, y conviene ser preciso con el inventario porque la frase se pierde un cambio no transmite el alcance. Desaparece el valor perdedor completo. Desaparece la señal de que existió una alternativa, porque el estado resultante es indistinguible de uno en el que solo hubo una escritura. Y desaparece la posibilidad de recuperación, porque el valor descartado no queda en ningún sitio del que se pueda sacar.

Hay una pérdida adicional que depende solo de la granularidad y que sorprende a mucha gente: si el registro es el documento entero en lugar de cada campo, la escritura perdedora se lleva por delante campos que nadie disputaba. Dos personas editan una la fecha y otra el responsable, y quien llega con sello menor pierde también su edición aunque tocara un campo distinto. Bajar la granularidad a nivel de campo es la mejora más barata que existe en este territorio y la que más pérdida evita por línea escrita.

Y hay una pérdida que es propia del entorno local-first y que no aparece en un sistema conectado. Una escritura generada sin red se sella al escribirse y se envía tres días después, así que compite contra escrituras posteriores y pierde todas. Sellar en el momento del envío la haría ganar contra cambios que sí vieron el estado, lo cual es igual de incorrecto en la dirección contraria. Ninguna de las dos opciones es defendible, y esa ausencia de opción correcta es el diagnóstico del que sale la lección siguiente.

Las variantes que amortiguan el daño

Antes de saltar al registro multivalor conviene agotar lo que se puede hacer sin salir de esta política, porque tres de las cuatro mejoras son casi gratuitas y resuelven la mayor parte del dolor en un producto medio. La primera es la granularidad por campo. La segunda es el diario de descartes. La tercera es el sello monótono por réplica, que garantiza que dos escrituras del mismo dispositivo nunca compiten mal entre sí. La cuarta, y la única cara, es sustituir el registro por una estructura que conmute cuando el campo lo permita.

// Documento como mapa de registros independientes: cada campo compite por separado
function fusionarDocumento(a, b) {
  const salida = {};
  for (const clave of new Set([...Object.keys(a), ...Object.keys(b)])) {
    if (!(clave in a)) salida[clave] = b[clave];
    else if (!(clave in b)) salida[clave] = a[clave];
    else salida[clave] = fusionarLWW(a[clave], b[clave]);
  }
  return salida;
}

// Variante con diario: misma politica, pero la perdedora deja rastro
function fusionarConDiario(a, b, diario) {
  const gana = menor(a.sello, b.sello) ? b : a;
  const pierde = gana === a ? b : a;
  if (gana.valor !== pierde.valor) diario.push({ descartado: pierde, en: gana.sello });
  return gana;
}