El problema del registro: un valor, muchos dueños

Un registro es una celda: guarda un valor, lo lees, escribes encima. En una máquina sola es el tipo de dato más aburrido que existe, tan aburrido que ni siquiera lo llamamos tipo de dato; lo llamamos variable. Replicado entre dispositivos que se editan sin verse, ese mismo objeto trivial se convierte en el más difícil de los tipos elementales, y lo es por una razón que conviene tener delante durante los cinco niveles siguientes: incrementar acumula, insertar acumula, asignar destruye. Un contador converge porque dos incrementos concurrentes se pueden sumar; un conjunto converge porque dos inserciones concurrentes se pueden unir; dos asignaciones concurrentes no se pueden hacer las dos. Y sin embargo el registro es, con enorme diferencia, lo que hay dentro de una aplicación real: el título, el estado, la fecha límite, el responsable, el precio, el color de fondo. Es el tipo más frecuente del modelo y el peor resuelto del sector.

El tipo más simple, y lo que le pasa al replicarlo

La especificación secuencial de un registro cabe en una línea: leer devuelve el valor de la última asignar. Esa definición se apoya entera en la palabra última, y la palabra última presupone un orden total sobre las escrituras. En un proceso único ese orden lo regala el programa. Entre réplicas que editan sin verse, no existe: hay pares de escrituras que ninguna precede a la otra, y la especificación se queda literalmente sin significado. No es que el registro sea difícil de implementar; es que su definición deja de nombrar un objeto.

Conviene ver la divergencia en su forma mínima antes de razonar sobre ella, porque es más tonta de lo que uno espera y aparece sin necesidad de ningún escenario rebuscado.

// Registro ingenuo: el valor y nada mas
const crear = (valor) => ({ valor });
const asignar = (reg, nuevo) => ({ valor: nuevo });

// La fusion no tiene ninguna informacion con la que decidir
const fusionar = (a, b) => a; // cualquier eleccion aqui es arbitraria

const ana = asignar(crear("borrador"), "Informe Q1");
const luis = asignar(crear("borrador"), "Informe primer trimestre");

fusionar(ana, luis).valor; // -> Informe Q1
fusionar(luis, ana).valor; // -> Informe primer trimestre

Las dos últimas líneas son el problema entero. La fusión depende del orden de sus argumentos, y el orden de los argumentos depende de qué réplica llamó a quién, así que dos dispositivos que han visto exactamente las mismas escrituras terminan con estados distintos. El resultado no es un error visible ni una excepción: es una divergencia permanente que cada réplica considera el estado correcto.

La condición que hay que exigirle a la fusión para que eso no ocurra se conoce desde los trabajos de Shapiro y sus colaboradores en 2011, y no es negociable: la función tiene que ser conmutativa, asociativa e idempotente, es decir, tiene que ser el supremo de un semirretículo. Merece la pena escribirla como una comprobación ejecutable, porque es la prueba que hay que pasarle a cualquier registro que diseñes en el resto del nivel.

const igual = (x, y) => JSON.stringify(x) === JSON.stringify(y);

function verificarSemirreticulo(fusionar, muestras) {
  for (const a of muestras) {
    if (!igual(fusionar(a, a), a)) return "falla la idempotencia";
    for (const b of muestras) {
      if (!igual(fusionar(a, b), fusionar(b, a))) return "falla la conmutatividad";
      for (const c of muestras) {
        const izquierda = fusionar(fusionar(a, b), c);
        const derecha = fusionar(a, fusionar(b, c));
        if (!igual(izquierda, derecha)) return "falla la asociatividad";
      }
    }
  }
  return "cumple las tres";
}

verificarSemirreticulo(fusionar, [ana, luis]); // -> falla la conmutatividad

Asignar destruye, y por eso hay que enriquecer el estado

La pregunta correcta no es por qué falla el registro, sino por qué no fallan los otros. Un contador converge porque el efecto de un incremento es acumulativo: el estado después de dos incrementos contiene a los dos, y la fusión solo tiene que evitar contarlos dos veces. Un conjunto converge por lo mismo: la unión de dos inserciones contiene ambas. En los dos casos el estado crece de forma monótona, y sobre un estado que solo crece siempre se puede definir un supremo.

La asignación rompe justo esa propiedad. Su efecto no es añadir sino sustituir, de modo que el estado después de dos asignaciones no contiene a las dos: contiene a una. Un tipo cuyo estado no crece no vive en ningún retículo, y sin retículo no hay convergencia posible. Esta es la razón profunda, y no un detalle de implementación, por la que no existe el registro replicado: existen varios, y cada uno es una manera distinta de fabricar artificialmente el crecimiento que la asignación no tiene.

De ahí sale la ecuación que gobierna el nivel entero y que conviene memorizar tal cual: el estado replicado es el valor más un metadato. El valor es lo que el usuario cree que está guardando; el metadato es lo que hace posible el supremo. Toda la variedad de registros que verás en las lecciones siguientes se reduce a dos decisiones sobre esa segunda mitad: qué metadato se adjunta y cómo la lectura vuelve a proyectar el estado enriquecido sobre algo que la aplicación pueda pintar.

flowchart LR
V[valor que el usuario escribe] --> E[estado replicado]
M[metadato que ordena o distingue] --> E
E --> F[supremo bien definido]
F --> L[lectura que proyecta a la interfaz]
L --> U[un valor unico o un conjunto]
style E fill:#89b4fa,color:#11111b
style U fill:#f9e2af,color:#11111b

Escrito como código, ese patrón es el molde del que salen las dos construcciones del nivel. Un registro replicado son siempre tres funciones: una que enriquece la escritura, una que fusiona estados enriquecidos y una que proyecta el resultado hacia la aplicación. Cambiar de política es cambiar las tres a la vez, nunca una sola.

// El molde. Las lecciones 2 y 3 son dos rellenos distintos de estas tres ranuras
function definirRegistro({ enriquecer, supremo, proyectar }) {
  return {
    asignar: (contexto, valor) => enriquecer(contexto, valor),
    fusionar: (a, b) => supremo(a, b),
    leer: (estado) => proyectar(estado),
  };
}

La ranura que decide todo lo demás es la tercera, y por eso conviene mirarla antes que ninguna. Si proyectar devuelve un valor, la aplicación de arriba no tiene que enterarse de nada y el precio está enteramente escondido dentro de supremo, que habrá tenido que descartar algo. Si proyectar devuelve un conjunto, no se descarta nada y el precio sube hasta la interfaz, que ya no puede pintar el campo sin decidir qué hace con dos. La elección entre las dos políticas del nivel es, literalmente, la elección del tipo de retorno de esa función.

Las tres salidas, y ninguna es gratis

Solo hay tres maneras de fabricar el crecimiento que falta, y todo lo que existe en producción es una de las tres o una mezcla explícita de ellas. La primera es ordenar: adjuntar una marca que induzca un orden total sobre las escrituras, redefinir última como la de marca mayor y quedarse con ella. La segunda es conservar: adjuntar contexto causal, detectar que dos escrituras fueron concurrentes y devolver las dos, trasladando la decisión a quien pueda tomarla. La tercera es descomponer: reconocer que ese campo no debería haber sido un registro, y sustituirlo por una estructura cuya operación sí conmute —un contador, un conjunto, una secuencia—.

La tercera es la más potente y la menos aplicada, porque exige cambiar el modelo de datos en lugar de cambiar la librería de sincronización. Un campo etiquetas modelado como registro de una lista pierde las etiquetas que añadió el otro; modelado como conjunto con semántica de observación no pierde ninguna. La diferencia no está en el motor: está en haber mirado el campo y haber preguntado qué operación estaba ocurriendo de verdad debajo de la asignación.

Por qué es el caso más común y el peor resuelto

Cuenta los campos de cualquier modelo real. La inmensa mayoría son registros: cadenas cortas, fechas, enumerados, referencias, números que no se incrementan sino que se fijan. Los contadores son un puñado, los conjuntos unos pocos, el texto colaborativo suele ser uno o dos campos de todo el producto. Y sin embargo la literatura, las conferencias y las demostraciones se dedican casi por completo al texto colaborativo, porque es el caso vistoso, mientras que el campo estado de una tarea —que se edita cien veces más y se pierde cien veces más— no aparece en ninguna parte.

El desequilibrio tiene una consecuencia concreta y medible en cualquier producto en producción: el texto está bien resuelto por una librería madura y todo lo que lo rodea está resuelto por el valor por defecto de esa misma librería, que casi siempre es la primera salida sin que nadie la haya elegido. La pérdida no se concentra donde se puso el esfuerzo; se concentra en los cuarenta campos sobre los que no se pensó.

Hay además una razón estructural por la que el problema no se corrige solo con el tiempo, y es la ausencia de realimentación. Un fallo de sincronización que rompe la aplicación se arregla en horas porque interrumpe a alguien; un registro que descarta la escritura de un usuario no interrumpe a nadie, no genera excepción, no aparece en la telemetría y produce como único síntoma una incidencia de soporte imposible de reproducir. El sistema no tiene manera de saber que perdió algo, así que tampoco puede contarlo, y lo que no se cuenta no entra nunca en la lista de prioridades.