PN-Counter: restar rompe la monotonía y la solución es contar dos veces

El contador creciente funcionaba por una razón que ahora conviene recordar con precisión: cada casilla del mapa solo subía, de modo que el máximo entre dos versiones de la misma casilla siempre elegía la más informada. Basta con permitir que una casilla baje para que ese razonamiento se desmorone entero, y no de forma sutil: una resta seguida de una fusión con cualquier copia anterior queda deshecha, y queda deshecha una y otra vez cada vez que aparece un rezagado, sin error, sin aviso y sin manera de detectarlo desde dentro del sistema. La reparación es de una economía notable y establece el patrón que se repetirá durante el resto del track: en lugar de buscar una fusión más lista, se descompone la operación conflictiva en dos operaciones que sí son monótonas —incrementos por un lado, decrementos por otro— y se reconstruye el valor observable restándolas en el momento de leer. Esta lección construye esa estructura, demuestra que sigue siendo correcta, y examina lo que se paga y lo que, pese a las apariencias, no se recupera.

El decremento deshace la única regla que funcionaba

La tentación es evidente y hay que agotarla antes de descartarla: si incrementar era sumar a la casilla propia, decrementar debería ser restar de la casilla propia, dejando el resto de la estructura intacto. El fallo aparece en la primera fusión con una copia rezagada, que en local-first no es un caso raro sino el caso normal.

// Lo que NO funciona: dejar que una casilla baje y seguir fusionando por maximo
let ana = { ana: 5 };            // Ana ha aportado cinco
ana = { ana: ana.ana - 3 };      // Ana resta tres en su propia casilla: queda 2

const rezagado = { ana: 5 };     // una copia anterior que seguia circulando
fusionar(ana, rezagado);         // { ana: 5 }: la resta se ha deshecho sola

// Y no es un problema del maximo: con la suma seria { ana: 7 }, aun peor

Conviene ver por qué el daño es peor de lo que sugiere el ejemplo. La copia rezagada no tiene que venir de otra réplica: puede ser una copia de seguridad restaurada, un mensaje reentregado por el transporte o el propio estado que el dispositivo guardó en disco antes de la resta. Y como el máximo es idempotente, la restauración no ocurre una vez y se corrige: ocurre cada vez que ese estado antiguo vuelve a aparecer, de modo que la resta se deshace indefinidamente y el usuario ve un número que se niega a bajar. Es el mismo síntoma que producía un reloj que retrocede en el nivel veintitrés, y por el mismo motivo de fondo: se ha construido una operación que baja en un orden donde la fusión asume que todo sube.

La lectura general del fallo merece enunciarse porque se aplicará a docenas de casos: la corrección de una fusión por cota superior mínima no depende de la fusión, depende de que todas las operaciones locales sean monótonas respecto del orden. Si una sola operación baja, la estructura deja de converger hacia el estado correcto y pasa a converger hacia el máximo histórico, que es una cosa distinta y casi siempre indeseable.

Dos contadores que solo crecen y una resta al leer

La descomposición es directa. Se guardan dos mapas: uno para los incrementos, llamado tradicionalmente P por positivo, y otro para los decrementos, llamado N por negativo. Cada uno de los dos es un contador creciente completo, con sus mismas reglas y su misma invariante de propiedad de casilla. Decrementar el contador no consiste en restar en ninguna parte: consiste en incrementar el mapa de decrementos. Y el valor observable es la diferencia entre las dos sumas, calculada al leer.

// PN-Counter: dos contadores crecientes y una resta en la lectura
function crearPN() {
  return { p: {}, n: {} };
}

function incrementarPN(c, replica, cantidad = 1) {
  return { p: incrementar(c.p, replica, cantidad), n: c.n };
}

function decrementarPN(c, replica, cantidad = 1) {
  return { p: c.p, n: incrementar(c.n, replica, cantidad) };
}

function valorPN(c) {
  return valor(c.p) - valor(c.n);
}

function fusionarPN(a, b) {
  return { p: fusionar(a.p, b.p), n: fusionar(a.n, b.n) };
}

La corrección se hereda sin necesidad de volver a demostrar nada, y ese es justamente el interés de la construcción. El producto de dos retículos es un retículo, y su cota superior mínima es la de cada componente por separado; como fusionarPN aplica la fusión conocida a cada mitad, es conmutativa, asociativa e idempotente por herencia directa. Las operaciones locales suben en el orden del producto, porque cada una toca una sola mitad y solo hacia arriba. No hay nada nuevo que probar: la novedad no está en el álgebra, está en la consulta.

// Comprobacion: dos replicas restan sin conexion y ninguna resta se pierde
let x = decrementarPN(incrementarPN(crearPN(), "ana", 10), "ana", 3); // ana ve 7
let y = decrementarPN(incrementarPN(crearPN(), "ben", 4), "ben", 1);  // ben ve 3

const unido = fusionarPN(x, y);
valorPN(unido);                                    // 10
valorPN(fusionarPN(fusionarPN(unido, x), y));      // 10, reentregas incluidas

flowchart TD
OP[operacion no monotona restar] --> D[descomponer en dos monotonas]
D --> P[mapa P de incrementos que solo crece]
D --> N[mapa N de decrementos que solo crece]
P --> F[fusion por maximo en cada mapa]
N --> F
F --> Q[consulta suma de P menos suma de N]
Q --> V[valor observable que si puede bajar]
style P fill:#a6e3a1,color:#11111b
style N fill:#a6e3a1,color:#11111b
style V fill:#f9e2af,color:#11111b

La monotonía se muda del valor al estado

Aquí está el desplazamiento conceptual que da valor a la lección y que conviene no pasar por encima. El valor observable de la estructura sí baja: es lo que se pedía. Lo que nunca baja es el estado interno, porque las dos mitades solo crecen. Hemos separado dos cosas que en el contador creciente estaban pegadas y que la intuición confunde con facilidad: la monotonía es un requisito del estado replicado, no una propiedad del dato que el usuario ve. Mientras el estado suba, la fusión es correcta; lo que la consulta haga después con ese estado —restar, filtrar, ordenar, negar— es asunto suyo y no afecta a la convergencia.

De ahí sale una consecuencia práctica que sorprende la primera vez y que produce errores reales: no se pueden comparar dos réplicas por su valor. Dos estados con el mismo valor observable pueden ser causalmente incomparables, y un estado con valor menor puede ser estrictamente más informado que otro con valor mayor. La pregunta quién va por delante solo tiene sentido en el retículo, es decir, comparando los dos mapas casilla a casilla, exactamente como hacía la función comparar de la lección anterior.

// El valor no ordena: hay que comparar los mapas, no los numeros
function compararPN(a, b) {
  const p = comparar(a.p, b.p);
  const n = comparar(a.n, b.n);
  if (p === n) return p;
  if (p === "iguales") return n;
  if (n === "iguales") return p;
  return "concurrentes";
}

Lo que se paga y lo que no se recupera

El coste inmediato es que el estado se duplica: dos mapas en lugar de uno, con sus dos juegos de identificadores de réplica. En la práctica el factor real es menor que dos, porque solo aparecen entradas para las réplicas que efectivamente escribieron en cada mitad, y en muchos modelos hay muchas más réplicas que incrementan que réplicas que decrementan. Aun así, el orden de magnitud es el mismo y hereda el problema que estudia la última lección del nivel: crece con el número de escritores.

Hay un coste menos visible y más importante, y es la pérdida de asociación entre incrementos y decrementos. La estructura sabe cuánto se sumó y cuánto se restó en total por réplica, pero no sabe qué decremento cancelaba qué incremento. Eso significa que no se puede consultar el histórico, no se puede deshacer una operación concreta y no se puede auditar quién revirtió qué. Si el dominio necesita esas preguntas, el contador no es la estructura adecuada y hay que subir a un conjunto de operaciones identificadas, que cuesta memoria proporcional al número de operaciones en lugar de al número de réplicas.

Existe una variante que reduce el estado a un solo mapa guardando un par de números por réplica en lugar de dos mapas separados, y es la que suele aparecer en las implementaciones de producción porque ahorra un juego de claves y una recorrida. No cambia nada del razonamiento: es la misma estructura con otra disposición en memoria, el par se fusiona tomando el máximo de cada componente por separado y sigue siendo válido exactamente por las mismas razones. Lo que no es una variante válida es guardar un único entero con signo por réplica y fusionar por máximo del valor absoluto o por cualquier otro criterio ingenioso: en cuanto una casilla puede bajar, el fallo de la primera sección vuelve entero.