Cuando la autoridad central es el producto

Un curso que solo vende su tema es propaganda, y este nivel entero existe para pagar esa deuda. Las lecciones anteriores han construido un argumento honesto a favor de mover el dato al cliente; esta empieza a construir el argumento contrario, y lo hace por el caso más limpio y menos discutible de todos: aquel en el que la decisión centralizada no es una limitación heredada de la arquitectura cliente-servidor, sino literalmente el servicio que se vende. Un banco que no puede afirmar cuánto dinero hay en una cuenta no es un banco lento, es otra cosa. Un sistema de reservas que a veces vende dos veces el mismo asiento no tiene un fallo, tiene otro modelo de negocio. Cuando la invariante global es el producto, replicarla es venderla rota, y hay una parte de esta afirmación que ni siquiera es una opinión de ingeniería: es un teorema.

La invariante global no es un detalle de implementación

Una invariante es un predicado que debe cumplirse sobre el estado completo del sistema en todo instante. La distinción que decide esta lección no es entre invariantes fáciles y difíciles, sino entre las que se pueden comprobar mirando un solo objeto y las que exigen mirar todos a la vez. Que el título de un documento no esté vacío se comprueba con el documento delante. Que la suma de los reintegros no exceda el saldo, que no haya dos reservas para el mismo asiento o que exista exactamente un ganador son predicados que cuantifican sobre el conjunto entero, y ninguna réplica ve el conjunto entero por definición: una réplica es, precisamente, una vista parcial que puede escribir sin preguntar.

Esa intuición tiene un nombre formal y un resultado detrás. La confluencia de invariantes dice que una invariante global se puede mantener sin coordinación si y solo si la fusión de dos estados válidos produce siempre un estado válido. saldo >= 0 no cumple esa condición: dos réplicas con saldo cien, cada una retirando ochenta, sostienen estados individualmente válidos cuya fusión es inválida. La unicidad tampoco la cumple, ni el aforo máximo, ni la asignación exclusiva de un identificador. El teorema CALM llega por el otro lado a la misma frontera: un programa admite implementación distribuida sin coordinación si y solo si es monótono, y toda regla de la forma no existe ningún otro es no monótona por construcción.

flowchart TB
A[invariante del dominio] --> B[se comprueba con un solo objeto delante]
A --> C[cuantifica sobre todas las replicas]
B --> D[replicable: el cliente puede decidir]
C --> E[la fusion de dos estados validos es siempre valida]
E --> F[si: replicable con cuidado]
E --> G[no: exige un punto de serializacion]
G --> H[hay servidor, se llame como se llame]
style D fill:#a6e3a1,color:#11111b
style F fill:#a6e3a1,color:#11111b
style H fill:#f38ba8,color:#11111b

Conviene subrayar por qué esto no es pesimismo sino economía. La coordinación no está prohibida en un sistema local-first; lo que está prohibido es fingir que no hace falta. Un diseño maduro localiza el punto exacto donde la coordinación es imprescindible, lo hace pequeño y lo aísla, en lugar de esparcirlo por toda la aplicación en forma de peticiones síncronas. La literatura distingue con precisión dos posturas que en la práctica se confunden: libre de coordinación, que significa que jamás se necesita un acuerdo, y evitando la coordinación, que significa que se paga solo cuando la invariante corre peligro real. La segunda es la postura profesional y no se puede adoptar sin haber inventariado antes las invariantes.

Ese inventario también corrige el uso perezoso del teorema CAP que circula por las presentaciones. CAP no dice elige dos de tres: dice que durante una partición hay que elegir entre responder y ser consistente, y no dice nada sobre el resto del tiempo. La consecuencia es que la pregunta correcta nunca es si tu sistema es AP o CP en abstracto, sino qué operación concreta prefiere fallar durante una partición y cuál prefiere aceptar. En un producto real esa respuesta cambia por endpoint: leer el histórico puede seguir disponible mientras firmar una transferencia se niega, y esa granularidad es donde vive todo el diseño interesante.

El catálogo de los dominios que no negocian

Los cuatro dominios que siguen no son una lista arbitraria: son las cuatro formas canónicas que adopta una invariante no confluente en un producto real. Casi cualquier caso difícil que encuentres es una variante de alguno de ellos, y reconocer la forma ahorra semanas de discusión sobre herramientas.

La columna del escape es la más instructiva de la tabla porque muestra que estos dominios no son igual de rígidos. El inventario admite una degradación elegante mientras haya holgura, y las reservas admiten una violación tarifada porque existe un mecanismo social de compensación. La banca y las subastas no admiten nada, y por motivos distintos: una porque el regulador no acepta aproximaciones, la otra porque el resultado del producto es exactamente la propiedad que se estaría relajando.

El cuarto merece un párrafo aparte porque desmonta un supuesto que atraviesa todo el track. Los relojes lógicos, los vectores de versión y los relojes híbridos resuelven el problema del orden entre réplicas que cooperan. Una subasta, una bolsa o cualquier mercado con prioridad temporal no cumple ese supuesto: el cliente que emite el evento se beneficia de mentir sobre cuándo lo emitió. Ninguna técnica de ordenación distribuida sin coordinación es robusta frente a un emisor que controla su propio contador, y por eso los mercados se implementan como un libro de órdenes centralizado incluso cuando la latencia es el activo más caro del negocio. Si el sector que más dinero gasta en reducir latencia acepta un punto de serialización, la latencia no era el argumento.

Hay un patrón transversal a los cuatro que merece nombrarse porque explica por qué tantos equipos se equivocan en la estimación inicial. En todos ellos la invariante se comporta de forma benigna mientras el recurso abunda y se vuelve rígida exactamente cuando escasea, que es cuando llega el pico de tráfico. Un catálogo con mil unidades tolera cualquier optimismo; el mismo catálogo con tres unidades y un lanzamiento anunciado no tolera ninguno. La consecuencia es que las pruebas en condiciones normales nunca detectan el problema: el sistema funciona de maravilla durante meses y falla el día que más gente lo mira. Diseñar para el caso abundante y descubrir el caso escaso en producción es la trayectoria estándar de este error.

Converger no es lo mismo que ser correcto

El eslogan de los CRDT dice sin conflictos, y esa frase se lee mal casi siempre. Lo que un CRDT garantiza es convergencia fuerte eventual: dos réplicas que han visto el mismo conjunto de operaciones están en el mismo estado. Es una propiedad sobre el acuerdo, no sobre la validez. Un contador con incrementos y decrementos converge impecablemente a menos treinta si eso es lo que dicen las operaciones. La fusión está definida; la invariante del dominio, violada. Todas las réplicas coinciden en el mismo estado incorrecto, que es una forma particularmente sofisticada de estar equivocado.

// Convergencia perfecta, dominio destruido.
// Dos replicas, saldo inicial 100, ambas offline.
replicaA.aplicar({ tipo: 'retirada', importe: 80 }); // A ve saldo 20, valido
replicaB.aplicar({ tipo: 'retirada', importe: 80 }); // B ve saldo 20, valido

fusionar(replicaA, replicaB); // saldo -60 en ambas: coinciden, y es ilegal

Conviene además desmontar la lectura publicitaria del término conflicto. Cuando un motor de sincronización promete que no hay conflictos, lo que promete es que la fusión nunca falla, es decir, que el algoritmo siempre devuelve algo. No promete que ese algo sea lo que ninguno de los dos usuarios quería, ni que conserve la intención de ambos, ni desde luego que respete una regla de negocio. Hay tres propiedades distintas apiladas bajo la misma palabra —ausencia de fallo de fusión, preservación de intención y validez del dominio— y solo la primera está garantizada. Confundirlas es el origen de la mayoría de las decepciones con estas herramientas.

La razón profunda es que un tipo replicado sin conflicto no puede rechazar. Rechazar exige conocimiento del conjunto completo en el instante de la escritura, que es justo lo que la réplica no tiene. Existen construcciones que parecen contradecir esto —contadores acotados, patrones de fianza o escrow que reparten un presupuesto entre réplicas— y estudiarlas es instructivo porque revelan la trampa: reparten permiso por adelantado. La coordinación no se elimina, se adelanta en el tiempo y se amortiza. Funciona cuando el recurso es fungible y abundante; se degrada a coordinación pura cuando escasea, y es inaplicable cuando el recurso es único, porque un asiento no se puede dividir en presupuestos.

// El patron de fianza: coordinar una vez, decidir localmente despues.
// El coordinador reparte permiso por adelantado entre replicas.
const presupuesto = await coordinador.reservar({ recurso: 'unidades', cantidad: 50 });

// A partir de aqui la replica decide sola y sin red, pero solo hasta 50.
if (presupuesto.consumir(1)) {
  confirmarVenta();          // decision local, instantanea, correcta
} else {
  await coordinador.pedirMas(); // se acabo la holgura: vuelve la coordinacion
}
// La invariante se respeta porque nadie repartio mas permiso del que habia.
// El precio: hay stock inmovilizado en replicas que quiza no venden nada.

Ese fragmento resume la única forma honesta de comprar autonomía local sobre una invariante global: inmovilizar recurso. La réplica decide sin red porque alguien le entregó antes una porción exclusiva del derecho a decidir, y esa porción no está disponible para nadie más aunque no se use. Cuando el recurso abunda, el desperdicio es irrelevante y el patrón parece magia. Cuando escasea, el desperdicio es exactamente lo que no te puedes permitir, y el sistema degrada a pedir permiso en cada operación, que es el cliente-servidor del que se quería huir, ahora con más piezas.

Merece la pena extraer la moraleja general porque se aplica mucho más allá de los contadores. Toda técnica que promete decisión local sobre una invariante global funciona repartiendo autoridad por adelantado, y repartir autoridad por adelantado significa decidir antes con menos información. Eso es un intercambio, no una victoria: se gana latencia y disponibilidad, se pierde utilización del recurso y capacidad de reaccionar a lo que ocurra después del reparto. Un ingeniero que sabe nombrar ese intercambio puede negociarlo con el negocio; uno que cree haber eliminado la coordinación no puede ni explicar por qué hay existencias bloqueadas en un almacén que no vende.

Lo que sí queda para el cliente

Descartar el dato central no descarta la aplicación, y esta es la parte del argumento que los defensores del enfoque suelen conceder demasiado tarde y sus detractores nunca. Incluso en estos dominios existe una periferia amplia que es genuinamente del usuario y se beneficia entera del enfoque local: el borrador de una transferencia antes de firmarla, los filtros y la sesión de búsqueda de vuelos, el mapa de asientos que se explora, el carrito antes del pago, las notas internas de un gestor sobre un cliente, la lista de favoritos, el histórico ya liquidado que solo se lee. Ninguno de esos datos porta una invariante global, y todos se pueden hacer instantáneos, offline y duraderos sin comprometer nada.

La regla que ordena esa separación es corta: local para la intención, central para el compromiso. La intención es del usuario, existe en su cabeza antes de existir en ningún servidor y merece ser instantánea. El compromiso es una afirmación del sistema sobre el mundo compartido y solo la puede emitir quien tiene autoridad. El error caro no es respetar esa frontera, sino difuminarla en la interfaz: mostrar transferencia realizada sobre un estado optimista y deshacerlo veinte minutos después no es una mejora de la latencia percibida, es una mentira con consecuencias. En estos dominios, una espera honesta vale más que una confirmación falsa, porque lo que se está construyendo con cada confirmación no es una pantalla sino confianza.

De ahí sale una exigencia de vocabulario que suele quedarse fuera de las conversaciones de arquitectura y que en realidad las cierra. La interfaz debe tener palabras distintas para tres estados que el usuario percibe como uno solo: guardado en este dispositivo, enviado al servidor y confirmado por el servidor. Un producto que colapsa los tres en un tic verde ha decidido que su modelo mental sea más simple que su arquitectura, y esa diferencia la acaba pagando alguien en soporte. Cuando los tres estados son visibles, el optimismo deja de ser una mentira y se convierte en lo que siempre debió ser: una promesa acotada y revisable.

Existe además una razón operativa para respetar esta frontera aunque técnicamente pudieras saltártela. En los dominios regulados, la reconstrucción de lo ocurrido es un requisito con nombre propio, y reconstruir exige un registro autorizado, ordenado y no repudiable de las decisiones. Un histórico causal fusionado desde varias réplicas puede ser matemáticamente elegante y aun así no servir como prueba, porque la pregunta del auditor no es en qué orden convergieron los nodos sino quién decidió qué y cuándo lo supo el sistema. Esa pregunta solo la responde una autoridad.

Queda una objeción legítima que conviene atender antes de cerrar, porque quien la formula suele tener razón. Se puede argumentar que las cadenas de bloques resuelven exactamente esto sin servidor, y en cierto sentido lo hacen: producen un orden total acordado entre participantes que no confían entre sí. Pero el precio de esa proeza es informativo, porque consiste en pagar coordinación de forma explícita, costosa y lenta en cada escritura, con un mecanismo de consenso que existe precisamente porque el problema no admite atajos. No es un contraejemplo a esta lección: es su confirmación más cara. Cuando la invariante global es el producto, alguien paga coordinación, y la única decisión de diseño disponible es quién la paga y con qué moneda.