Por qué los índices no valen: tu tres ya no es mi tres

La lección anterior dejó establecido que la posición es un dato que hay que representar. Falta explicar por qué el candidato obvio —el índice, ese número que todos los lenguajes usan para hablar de listas— es justamente el candidato imposible. La respuesta cabe en una frase y conviene leerla despacio: un índice no nombra un elemento, nombra una cuenta de elementos anteriores, y esa cuenta cambia cada vez que alguien inserta o borra por delante. Cuando tú y yo trabajamos sobre copias distintas, mi historia y tu historia divergen, y tu número tres está expresado en unas coordenadas que en mi copia ya no existen. Esta lección diseca esa avería y presenta las dos escuelas que nacieron de ella: una que traduce los números de un sistema de coordenadas al otro, y otra que decide no tener números que traducir.

Un índice nombra una cuenta, no un elemento

Cuando escribes lista[3] no estás señalando a un objeto: estás pidiendo el objeto que quede después de saltar tres. El índice es una descripción por rodeo, y su referente depende por completo del contenido de lo que hay delante. En una estructura de datos local esa dependencia es inofensiva, porque solo hay una copia y solo hay una historia. En cuanto existen dos copias, la misma expresión pasa a designar objetos distintos en cada una, y ninguna de las dos está equivocada: ambas evalúan correctamente una descripción que dejó de ser la misma descripción.

Hay una comprobación mental que delata al culpable en cualquier sistema: pregúntate si el valor que estás enviando seguiría significando lo mismo dentro de un mes, en otra máquina, sobre un estado que ha cambiado. Un identificador pasa esa prueba; un índice no la pasa ni un segundo después de haberlo calculado.

El caso mínimo es de manual y conviene tenerlo memorizado, porque es la forma que adoptan casi todos los fallos reales. Partimos de la lista [a, b, c, d]. Tú insertas X en la posición tres, con la intención evidente de dejarlo entre c y d. Yo, sin verte, borro la posición uno, que es b. Cuando mi borrado llega a tu copia y tu inserción llega a la mía, si ambos aplicamos los números tal cual llegaron, tu X aterriza en un sitio que nunca quisiste.

flowchart TD
I[estado inicial a b c d] --> T[tu insertas X en el indice 3]
I --> Y[yo borro el indice 1 que es la b]
T --> TA[tu copia a b c X d]
Y --> YA[mi copia a c d]
TA --> F[aplico tu insercion tal cual en el indice 3]
YA --> F
F --> R[resultado a c d X en vez de a c X d]
style R fill:#f38ba8,color:#11111b

Lo que ha pasado tiene un nombre preciso: tu operación venía expresada en el sistema de coordenadas del estado [a, b, c, d], y yo la he aplicado sobre el estado [a, c, d], que es un sistema de coordenadas distinto. Nadie ha programado mal nada. El error está en haber transportado un número entre dos marcos de referencia sin convertirlo, y es exactamente el mismo tipo de error que sumar millas a kilómetros.

Vale la pena aislar la condición exacta bajo la que aparece el desfase, porque delimita cuándo puedes ignorarlo y cuándo no. Una operación remota con índice i es segura únicamente si todas las operaciones locales que ella no vio actuaron en posiciones mayores o iguales que i. Basta con que una sola de ellas haya tocado el prefijo para que el número llegue corrido, y el corrimiento se acumula: tres borrados por delante desplazan tres posiciones. Como no hay forma de saberlo mirando la operación, el receptor necesita conocer la historia completa que el emisor no vio, y ese requisito es el que arrastra toda la complejidad posterior.

// Aplicar tal cual: correcto solo si nada concurrente toco el prefijo
function esSeguraSinTransformar(remota, localesNoVistas) {
  return localesNoVistas.every((op) => op.indice >= remota.indice);
}

const remota = { tipo: "ins", indice: 3, valor: "X" };
esSeguraSinTransformar(remota, [{ tipo: "del", indice: 5 }]); // true
esSeguraSinTransformar(remota, [{ tipo: "del", indice: 1 }]); // false: corrimiento

La escuela que traduce: transformación operacional

La primera respuesta histórica al problema es la más directa: si el número está expresado en unas coordenadas equivocadas, conviértelo. Esa es la idea entera de la transformación operacional, publicada en 1989 con el sistema GROVE y llevada al gran público veinte años después por el editor colaborativo de Google. Antes de aplicar una operación remota, se la transforma contra cada operación local que la remota no vio, ajustando su índice para compensar lo que esas operaciones movieron.

// Transformar una insercion contra un borrado concurrente que la precede
function transformarInsercionContraBorrado(ins, del) {
  if (del.indice < ins.indice) return { ...ins, indice: ins.indice - 1 };
  return ins; // el borrado ocurria detras y no desplaza nada
}

const tuya = { tipo: "ins", indice: 3, valor: "X" };
const mia  = { tipo: "del", indice: 1 };

transformarInsercionContraBorrado(tuya, mia); // indice 2, que es lo que querias

La función parece sencilla y en este caso lo es. La dificultad aparece cuando se enumeran todos los pares posibles de tipos de operación, todas las posiciones relativas dentro de cada par y todas las combinaciones de tres o más operaciones concurrentes. Un sistema de transformación completo debe satisfacer dos propiedades de consistencia con nombre propio, y la segunda de ellas —la que exige que transformar en distinto orden dé el mismo resultado— resultó estar incumplida durante años en varios algoritmos publicados y revisados por pares. La lista de artículos que corrigen artículos anteriores es uno de los folclores más citados del campo.

Conviene entender de dónde sale esa dificultad, porque no es descuido de nadie. El número de casos que hay que cubrir crece con el cuadrado del número de tipos de operación, y cada caso exige decidir el comportamiento cuando las posiciones coinciden exactamente, que es donde se esconden casi todos los fallos. Peor aún, la segunda propiedad de consistencia relaciona tríos de operaciones concurrentes, de modo que ningún par de funciones puede verificarse por separado: la corrección es una propiedad del conjunto entero de transformaciones, y comprobarla a mano sobre una tabla de dos dígitos de entradas es exactamente el tipo de tarea en la que la revisión humana falla.

La escuela que evita: no tener números que traducir

La segunda respuesta llega en 2006 con WOOT y da un rodeo que en su momento pareció extravagante. Si el problema nace de que el índice es relativo a una historia, deja de usar índices. Que cada elemento reciba en el momento de insertarse un identificador propio, inmutable y comparable, y que la operación de inserción no diga en la posición tres sino con este identificador, que significa lo mismo en todas las réplicas y en todos los momentos porque no depende de qué haya delante.

El rodeo pareció extravagante por una razón concreta que hoy se olvida: en 2006 la memoria y el ancho de banda eran mucho más caros, y proponer que cada carácter de un documento cargara con varios bytes de metadatos permanentes sonaba a despilfarro frente a un método ya probado que enviaba tres campos por operación. Lo que cambió el veredicto no fue una mejora del algoritmo sino un cambio en el precio relativo de los recursos, más la aparición de un requisito nuevo —trabajar sin ningún servidor que serialice— que la transformación operacional cumple mucho peor. Es un buen recordatorio de que las decisiones de arquitectura envejecen cuando cambian los costes, no solo cuando aparecen ideas mejores.

El cambio de coste que introduce ese rodeo es el eje que gobierna todo lo que queda del nivel. Transformar es barato en espacio y caro en lógica: la operación pesa unos pocos bytes y la corrección exige un enrejado de casos que hay que demostrar. Evitar es lo contrario: la lógica de fusión se reduce a unir conjuntos y ordenar, algo que se demuestra en un párrafo, pero cada elemento arrastra para siempre un identificador que hay que guardar, transmitir y comparar.

// La misma insercion expresada de las dos maneras
const porIndice = { tipo: "ins", indice: 3, valor: "X" };
// Solo es interpretable sabiendo exactamente que habia delante

const porIdentificador = { id: "0.625", valor: "X" };
// Interpretable siempre: va entre todo lo menor y todo lo mayor que 0.625

Repara en que el segundo objeto no menciona ningún estado, ninguna historia y ninguna réplica. Es una afirmación autocontenida sobre dónde vive ese carácter, y por eso puede llegar tarde, repetido o en cualquier orden sin que su significado se altere. Esa autonomía es lo que permite que la fusión sea idempotente y conmutativa sin esfuerzo, y es también lo que obliga a pagar el espacio del identificador: la información que la transformación reconstruye en el momento de aplicar, el identificador la lleva escrita encima desde que nace.

La idempotencia merece un comentario aparte porque es una ventaja operativa que se subestima. Con transformación, entregar dos veces la misma operación corrompe el documento, así que el transporte debe garantizar entrega exactamente una vez y en el orden causal correcto, lo cual obliga a numerar, acusar recibo y recuperar huecos. Con identificadores, aplicar dos veces la misma inserción no hace nada porque insertar en un conjunto lo que ya está es una operación neutra, y eso permite transportes mucho más tontos: reenviar sin miedo, sincronizar por diferencia de conjuntos, aceptar mensajes duplicados de dos rutas distintas. Buena parte de la simplicidad operativa de los sistemas local-first modernos viene de aquí y no del algoritmo en sí.

Queda una objeción que conviene atender antes de cerrar la sección, porque se plantea siempre. Si el identificador es autocontenido, ¿no bastaría con dar a cada elemento un identificador aleatorio y ordenarlos por él? No, y el motivo es exactamente el que ocupa la lección siguiente: un identificador aleatorio ordena, pero no permite pedir quiero estar entre estos dos, que es lo único que hace falta para insertar en medio. Ordenar y poder insertar en cualquier hueco son requisitos distintos, y el segundo es el difícil.

Lo que las dos escuelas comparten

Vale la pena cerrar sin maniqueísmo, porque las dos familias resuelven el mismo problema y no son tan ajenas como sugiere su literatura. Ambas parten de aceptar que las réplicas divergen y que ninguna tiene autoridad; ambas exigen que el resultado sea independiente del orden de llegada; y ambas acaban necesitando algún tipo de contabilidad causal para saber qué operaciones se han visto ya. La diferencia está en dónde colocan la información que resuelve el desfase, y esa colocación es una decisión de ingeniería, no una cuestión de bandos.

De hecho, la frontera entre ambas es más porosa de lo que sugieren los nombres. Se ha demostrado que ciertos algoritmos de una familia se pueden reformular como algoritmos de la otra sin cambiar su comportamiento observable, lo cual indica que la distinción es de presentación tanto como de fondo. Lo que sí es una diferencia real y no reducible es el requisito topológico: si tu arquitectura garantiza un punto de serialización, tienes disponibles las dos familias y la transformación suele salir más barata; si no lo garantiza, y local-first consiste precisamente en no garantizarlo, la familia de los identificadores es la que queda en pie.

La transformación la coloca en el receptor, que reconstruye el ajuste a partir de lo que sabe. El CRDT la coloca en el dato, que nace con su posición dentro. Poner información en el receptor ahorra espacio y multiplica los casos; ponerla en el dato multiplica el espacio y colapsa los casos a uno. Los algoritmos modernos han empezado a mezclar ambas ideas —guardar operaciones al estilo de la transformación y reconstruir los identificadores solo cuando hace falta— y esa mezcla es una de las líneas más activas del campo hoy.

Hay una consecuencia práctica que conviene extraer antes de cerrar, porque afecta a decisiones que probablemente tengas tomadas ya. Aunque elijas el camino del identificador, tu interfaz sigue hablando en índices: el cursor está en la posición cuatrocientos doce, la selección va del mil al mil cincuenta, el elemento arrastrado venía del tercer puesto. Esa frontera entre la vista, que piensa en índices, y el modelo, que piensa en identificadores, es un sitio donde se acumulan errores reales, y la regla que los evita es simple de enunciar: traduce del índice al identificador en el instante en que el usuario actúa, nunca después. Guardar un índice para usarlo cuando llegue la respuesta del servidor es reintroducir el problema entero en la capa de presentación.