El primer eje, la autoridad: quién tiene derecho a decir que no

De los tres ejes que ordenan este nivel, el de la autoridad es el primero porque es el que condiciona a los otros dos y el que menos se puede cambiar después. Formulado como pregunta suena casi trivial: cuando un cliente hace una escritura, ¿existe alguien con potestad para rechazarla? En un extremo del eje la respuesta es sí y tiene nombre propio: hay un servidor que reevalúa cada mutación contra el estado canónico y emite un veredicto que el cliente acata, y Zero de Rocicorp lo dice sin rodeos en su propia documentación. En el otro extremo la respuesta es no, y no por descuido sino por construcción: se eligen estructuras cuya fusión está definida para cualquier par de estados, de modo que ningún estado es rechazable porque no hay nadie facultado para rechazarlo, que es el terreno de los tipos convergentes del bloque anterior. Entre los dos extremos hay un continuo poblado, y esta lección lo recorre entero para dejar claro qué se compra y qué se paga en cada punto, porque la elección no es de gusto arquitectónico sino de qué invariantes tiene tu dominio.

Servidor autoritativo: el derecho a decir que no

En este extremo el cliente no envía el resultado de su escritura sino la intención que la produjo: el nombre de una mutación y sus argumentos, no el estado al que llegó. La distinción parece menor y es la clave entera del modelo. Al recibir una intención, el servidor puede volver a ejecutarla contra el estado canónico, con los permisos reales, el reloj real y la secuencia real, y llegar a una conclusión que el cliente no estaba en condiciones de alcanzar. El cliente había calculado una hipótesis con la información parcial que tenía; el servidor calcula el hecho.

El ciclo completo tiene una pieza que suele pasarse por alto y que hace todo el trabajo fino. Cuando llega la respuesta autoritativa, el cliente no puede limitarse a aplicarla encima de lo que tenía, porque encima de su hipótesis pueden haberse acumulado otras mutaciones locales todavía sin enviar. Lo que hace es descartar su estado especulativo, adoptar el estado canónico recién llegado y reaplicar sobre él la cola pendiente, exactamente igual que una reubicación de commits en un control de versiones. Esa reaplicación es la razón de que las mutaciones tengan que estar escritas como funciones nombradas y reproducibles: van a ejecutarse muchas veces, en el cliente, y una vez, de verdad, en el servidor.

sequenceDiagram
participant C as cliente
participant S as servidor autoritativo
C->>C: aplica la mutacion en local de forma especulativa
C->>S: envia nombre y argumentos con un identificador
S->>S: reevalua contra el estado canonico y los permisos reales
S-->>C: veredicto aceptada o rechazada mas el estado resultante
C->>C: descarta lo especulativo y reaplica la cola pendiente

De aquí se deducen dos consecuencias que conviene tener presentes antes de enamorarse del modelo. La primera es que el cliente necesita suficientes datos en local para calcular su hipótesis: si la mutación consulta filas que nunca bajaron, la especulación es imposible y la escritura deja de ser instantánea. Ese acoplamiento entre autoridad y alcance reaparecerá con fuerza en la cuarta lección. La segunda es que el rechazo tiene un coste visible e ineludible: el usuario vio ocurrir algo y va a verlo deshacerse. La reversión no se puede ocultar, solo se puede diseñar, y esa reversión visible es el precio literal del derecho a decir que no.

Convergencia sin árbitro: nadie puede rechazar nada

En el extremo opuesto no hay veredicto porque no hay juez. Las réplicas intercambian estados u operaciones, y la fusión está definida para cualquier par: es conmutativa, asociativa e idempotente, de modo que dos réplicas cualesquiera pueden reconciliarse entre sí sin consultar a una tercera y llegar al mismo sitio con independencia del orden en que se enteren de las cosas. Un servidor, si existe, deja de ser autoridad y pasa a ser un intermediario que almacena y reenvía sin necesidad de entender el contenido. Jazz lleva ese planteamiento al extremo poniendo además cifrado por delante, de modo que el intermediario no solo no juzga: no puede juzgar, porque no ve.

La consecuencia dura de este extremo es que desaparecen las invariantes globales. No hay forma de garantizar que un nombre sea único, que un saldo no baje de cero, que un aforo no se rebase o que exactamente una persona ocupe un puesto, porque garantizar cualquiera de esas cosas exige que alguien vea todas las escrituras candidatas antes de admitir una, y eso es coordinación. El control de acceso también cambia de naturaleza: donde el servidor autoritativo valida, aquí se cifra y se firma. No puedes leer lo que no puedes descifrar y no puedes escribir lo que los demás no aceptarán como firmado por quien corresponde, que es una forma completamente distinta de decir lo mismo y con propiedades muy distintas al revocar.

// Autoritativo: el cliente propone, el servidor dispone
const veredicto = await servidor.ejecutar("transferir", { de, a, importe });
if (veredicto.rechazada) local.revertirYNotificar(veredicto.motivo);

// Sin arbitro: no hay veredicto posible, solo fusion
estadoLocal = fusionar(estadoLocal, estadoRemoto); // definida para todo par
// No existe un lugar donde escribir "saldo insuficiente": nadie tiene los dos saldos a la vez

La pregunta correcta no es cuál de los dos extremos es mejor, porque la respuesta depende enteramente de una propiedad de tu dominio que puedes calcular. Una invariante es cerrada bajo fusión cuando, siendo cierta en dos réplicas por separado, sigue siendo cierta en su fusión. Que un conjunto de etiquetas contenga solo etiquetas válidas lo es. Que una fecha sea posterior a otra suele serlo. Que un contador solo crezca lo es. Que un identificador sea único no lo es. Que un total no supere un tope no lo es. Las invariantes del primer grupo no necesitan árbitro y coordinar por ellas es tirar disponibilidad a la basura; las del segundo no sobreviven a ninguna cantidad de ingenio algebraico y exigen coordinación, aunque sea mínima y localizada.

Qué compra y qué paga cada extremo

Formulado con precisión, el intercambio es este: la potestad de rechazar es una forma de coordinación, y la coordinación es exactamente lo que hay que ceder para seguir disponible durante una partición. No es una metáfora ni una analogía suelta con los teoremas clásicos de sistemas distribuidos; es el mismo enunciado dicho con otras palabras. Un servidor autoritativo aislado de sus clientes tiene solo dos salidas y ambas son pérdidas: negarse a finalizar, con lo que la escritura se queda pendiente indefinidamente, o aceptar a ciegas, con lo que ya no es autoritativo. No hay una tercera puerta esperando a que alguien la descubra.

Conviene además desactivar una lectura moral del eje que circula bastante. El extremo sin árbitro no es el extremo puro ni el extremo virtuoso, del mismo modo que el autoritativo no es el pragmático ni el atrasado. Son dos maneras de repartir un coste fijo, y la que sobra en un dominio es imprescindible en el de al lado. Un editor colaborativo de notas personales no tiene ninguna invariante global que proteger y pagaría un peaje absurdo por un árbitro. Un sistema de reserva de asientos tiene una invariante que no es negociable, y venderla como convergencia elegante no la hace desaparecer: la convierte en una incidencia con dos personas sentadas en la misma butaca.

Un continuo, no un interruptor

Las posiciones intermedias son la mayoría y merecen nombre propio. La primera es la autoridad parcial por dominio: el servidor arbitra solo el puñado de mutaciones que tocan invariantes no cerradas bajo fusión, y deja convergir todo lo demás sin intervenir. Es la posición correcta en casi cualquier aplicación real, porque en un modelo típico la proporción de campos que necesitan árbitro es pequeña y aplicar coordinación a los demás es pagar por un seguro que no cubre nada.

La segunda es la asimetría entre caminos, y es lo que ocurre cuando alguien mira el giro que dio ElectricSQL en 2024 y no sabe dónde colocarlo. Ese modelo hace llegar filas autoritativas de Postgres al cliente sin exigirle estructuras convergentes, mientras que las escrituras suben por tu propia interfaz de servidor, que es autoritativa por definición porque es código tuyo ejecutándose junto a la base. El camino de bajada se comporta como una réplica y el de subida como una petición clásica: no es una posición confusa, es una decisión deliberada de no acoplar ambos caminos al mismo mecanismo.

La tercera, y la más sutil, es el arbitraje de orden sin arbitraje de contenido. Un sistema de registro de eventos como LiveStore mantiene un log determinista de mutaciones y deriva de él el estado en SQLite; el servidor que ordena ese log ejerce autoridad, pero solo sobre la secuencia, no sobre la validez semántica de cada entrada. Es autoridad en un sentido muy débil y a la vez suficiente para recuperar propiedades que la convergencia pura no da, como poder reconstruir el estado exacto de cualquier cliente en cualquier punto y poder razonar sobre un antes y un después que todos comparten.