El eje de la autoridad

Las tres lecciones anteriores han ido descartando candidatos. La conectividad no ordena el campo, porque hay sistemas soberanos que no arrancan sin red y sistemas del servidor que funcionan un mes en un avión. El volumen de datos replicados tampoco, porque una caché completa sigue siendo una caché. La tecnología de sincronización menos aún, porque el mismo motor puede servir a arquitecturas con constituciones opuestas. Lo que queda, y lo que sí ordena todo, es una sola pregunta con tres respuestas posibles: cuando dos versiones del mismo dato discrepan, ¿quién tiene la potestad de decidir cuál es la verdad? Ese es el eje. Todo lo demás en este campo —qué invariantes puedes garantizar, cómo modelas los permisos, qué haces con los conflictos, cómo evolucionas el esquema, qué le puedes prometer al usuario— se deduce de la posición que ocupes en él.

Una pregunta con tres respuestas

Reformulemos la pregunta con el cuidado que merece, porque su fuerza está en su precisión. No es quién guarda los datos, que puede ser todo el mundo a la vez. No es quién los escribe primero, que casi siempre es el cliente. Es quién dirime: cuando existen dos versiones de un mismo hecho producidas de forma concurrente y hay que quedarse con una historia, ¿de quién es la decisión?

Solo hay tres formas de responder. La primera es nombrar un árbitro y darle la última palabra. La segunda es declarar que cada réplica es soberana sobre lo que escribe y que nadie puede revocarlo. La tercera es negar que haga falta decidir: definir la fusión de forma que cualquier orden de llegada produzca el mismo resultado, y con ello convertir la pregunta en irrelevante. No hay una cuarta, y esa exhaustividad es lo que hace del eje una herramienta de clasificación y no una metáfora.

La exhaustividad no es una intuición feliz: se sigue de la estructura del problema. Si dos escrituras concurrentes deben producir un único resultado, o bien alguien elige entre ellas —y entonces hay un decisor, dentro o fuera del cliente— o bien la elección está predeterminada por la propia operación de combinación, en cuyo caso no hay decisor y el resultado es función de las entradas y no del orden. Las dos primeras posiciones se distinguen solo por dónde está sentado el decisor; la tercera es cualitativamente distinta porque elimina el papel.

Conviene también notar que la pregunta se puede plantear sobre cualquier granularidad y que la respuesta cambia con ella. Un producto entero rara vez tiene una sola respuesta; una entidad casi siempre tiene una; y un campo dentro de una entidad puede tener otra distinta que la entidad que lo contiene. El texto de un documento puede converger mientras su título lo dicta el último que lo cambió y su lista de permisos la dicta un árbitro. Esa granularidad fina es lo que separa un diseño pensado de una elección de biblioteca aplicada uniformemente.

flowchart LR
A[autoridad en el servidor] --- B[autoridad en el cliente] --- C[convergencia sin autoridad]
A --> A1[un arbitro decide y puede rechazar]
B --> B1[la escritura local es final]
C --> C1[el algoritmo garantiza el mismo resultado]
style A fill:#f38ba8,color:#11111b
style B fill:#94e2d5,color:#11111b
style C fill:#cba6f7,color:#11111b

Dibujarlo como una recta tiene una virtud y un riesgo. La virtud es que se ve el desplazamiento progresivo de la potestad desde un punto central hacia el borde y finalmente hacia ninguna parte. El riesgo es leer la recta como una escala de calidad, con la izquierda como pasado y la derecha como futuro. No lo es: son tres compromisos distintos con costes distintos, y hay problemas para los que cada uno de los tres es la única respuesta razonable.

Hay un motivo estructural por el que ninguna de las tres puede desplazar a las otras, y es viejo en la teoría de sistemas distribuidos. Bajo partición de red, un sistema puede seguir aceptando operaciones o puede seguir garantizando una vista única y coherente, pero no ambas cosas; y esa disyuntiva no se resuelve con mejor ingeniería porque no es un problema de implementación. Las tres posiciones del eje son simplemente tres respuestas coherentes a esa disyuntiva, tomadas en distintos puntos y con distintos beneficiarios. Mientras la física de la red siga siendo la que es, las tres seguirán teniendo dominios donde son la elección correcta.

Las tres posiciones

Un matiz que evita una confusión frecuente: la segunda posición no exige que no haya servidor, exige que el servidor no juzgue. Puede almacenar, puede reenviar, puede indexar, puede cobrar por hacerlo y puede ser operado por la misma empresa que vende el producto. Lo que no puede es rechazar una escritura ya realizada por el usuario. La diferencia entre un servidor que guarda y un servidor que decide es invisible en un diagrama de cajas y es la única que importa para clasificar.

Los motores de sincronización de 2026 se reparten por este eje y suelen ser explícitos sobre dónde se colocan, lo que los convierte en buenos ejemplos para fijar las posiciones. Zero, de Rocicorp, se sitúa sin ambigüedad en el extremo izquierdo: su servidor reejecuta las mutaciones y tiene la facultad de aceptarlas o rechazarlas, y esa decisión es deliberada porque es lo que le permite ofrecer permisos y reglas de negocio con garantías. Jazz empuja hacia el extremo derecho, con un modelo descentralizado y cifrado en el que el servidor no puede arbitrar lo que ni siquiera puede leer. ElectricSQL ocupa una posición intermedia que merece su propio apartado, porque su rediseño de 2024 hace algo que el eje simple no captura del todo: transmite en continuo porciones de tablas de una base Postgres hacia el cliente sin exigirle estructuras convergentes, replicando la lectura sin desplazar la autoridad de escritura. Cómo funciona cada uno por dentro es materia del nivel 52; aquí solo nos interesa que las tres posiciones están pobladas por sistemas reales y en producción.

Las tres posiciones se pueden mezclar dentro de un mismo producto, y los sistemas maduros lo hacen. Un editor colaborativo puede resolver el cuerpo del documento por convergencia, porque ahí lo que importa es que nadie pierda tecleo y que todos vean lo mismo, y a la vez enviar el cambio de propietario del documento a un árbitro central, porque ahí lo que importa es que el resultado sea correcto según una regla. Elegir posición por tipo de dato en vez de por aplicación entera es señal de madurez de diseño, no de indecisión.

Merece la pena hacer explícito el criterio con que se reparte. Los datos cuya semántica es acumulativa —texto que se escribe, elementos que se añaden, anotaciones, registros de actividad— toleran bien la convergencia porque toda contribución es válida y el peor resultado de una fusión es un exceso, no una violación. Los datos cuya semántica es exclusiva —quién ocupa un puesto, qué identificador es único, cuánto queda de un recurso limitado— necesitan un árbitro porque su corrección depende de que alguien vea el conjunto entero. Clasificar el modelo de datos según esa distinción, antes de elegir tecnología, es probablemente el ejercicio de diseño de mayor rendimiento en este campo.

Un caso límite que ilustra bien la frontera es el de la eliminación. Añadir es acumulativo y converge sin drama; eliminar es una afirmación sobre la ausencia, y la ausencia no se puede replicar como se replica una presencia, porque un dispositivo que nunca vio el elemento no puede distinguir entre no haberlo recibido y haberlo visto borrar. Todos los sistemas convergentes serios tienen una respuesta explícita a esa asimetría, y su coste —marcas de borrado que hay que conservar— es una de las razones por las que la convergencia no sale gratis en almacenamiento.

Leer y escribir pueden tener dueños distintos

El eje se vuelve mucho más útil cuando se le añade una segunda dimensión: la autoridad no tiene por qué ser la misma para la lectura que para la escritura. Es una separación que la mayoría de las discusiones omite y que explica arquitecturas que de otro modo parecen incoherentes.

La razón de que la separación sea posible es que ambas responden a preguntas distintas. La autoridad de lectura pregunta quién decide qué puedes ver y desde dónde lo obtienes; la de escritura pregunta quién decide si lo que haces cuenta. Un sistema puede replicar generosamente hacia el cliente todo lo que este tiene derecho a ver, para que lo consulte sin latencia y sin red, y conservar íntegro el poder de rechazar lo que ese mismo cliente intente escribir. No hay ninguna contradicción: son dos permisos independientes sobre el mismo dato.

La segunda fila es donde vive la mayor parte de lo que hoy se anuncia como local-first, y no es un fraude: replicar la lectura elimina la ruleta de carga, que es el ideal más visible del manifiesto. Lo que ocurre es que se cobra por un ideal y se factura como si se hubieran cumplido los siete. La tercera fila es la única que puede reclamar el término en su acepción fuerte, y su rareza relativa es una medida honesta de lo caro que sale.

La cuarta fila merece un comentario porque su rareza es informativa. Un sistema en el que la escritura es local y final pero la lectura debe pedirse al servidor combina lo peor de ambos mundos: no puedes prometer disponibilidad, porque leer requiere red, y tampoco puedes prometer corrección global, porque no controlas las escrituras. Se encuentra ocasionalmente como resultado accidental de una migración a medias, y detectarla es casi siempre el hallazgo más valioso de una auditoría de arquitectura.

Separar los dos ejes también aclara por qué la migración de una arquitectura a otra es tan asimétrica en dificultad. Mover la autoridad de lectura al cliente es un trabajo grande pero acotado: hay que decidir qué subconjunto replicar, mantenerlo fresco y reescribir el acceso a datos. Mover la autoridad de escritura al cliente toca la definición misma de qué es correcto en tu dominio, y por eso rara vez se hace en un producto ya lanzado sin reescribir el modelo.

Qué puede prometer cada posición

Termino con lo que hace del eje una herramienta y no una taxonomía decorativa: la posición determina el conjunto de promesas disponibles, y esa determinación es dura, no una cuestión de esfuerzo de ingeniería. Es la diferencia entre un problema difícil, que se resuelve con talento y tiempo, y un problema imposible, que no se resuelve. Confundirlos hace que los equipos gasten trimestres persiguiendo garantías que su arquitectura excluye por construcción.

Un árbitro central puede garantizar unicidad global, límites que no se pueden exceder y transiciones que dependen de ver el estado completo: un identificador que solo puede existir una vez, un saldo que no baja de cero, una plaza que se asigna a una sola persona. Puede hacerlo porque serializa todas las escrituras y ninguna se le escapa. Su coste es exactamente el reverso: como ninguna escritura es firme hasta que él la ve, ningún cliente puede prometerle nada al usuario en ausencia de red salvo intentarlo.

El rasgo común de todos los invariantes que solo un árbitro puede sostener es fácil de reconocer una vez formulado: son afirmaciones sobre el conjunto, no sobre un elemento. Que este documento tenga este texto es una afirmación local y no necesita a nadie más; que este nombre no lo use ningún otro usuario es una afirmación sobre todos los usuarios y no se puede verificar sin verlos a todos. Cuando dudes de si una regla necesita árbitro, comprueba si su enunciado contiene un cuantificador sobre el conjunto entero. Si lo contiene, necesita árbitro.

Conviene además reconocer que un árbitro central no es solo una restricción técnica sino a veces un requisito externo. Hay dominios en los que alguien debe poder responder por el estado ante un tercero —un regulador, un auditor, un tribunal— y esa responsabilidad exige un punto que conozca el estado completo y pueda certificarlo. En esos casos la posición de la izquierda no se elige por conveniencia de ingeniería sino porque la alternativa no es legalmente sostenible, y ninguna sofisticación en el cliente cambia esa realidad.

Una réplica primaria puede prometer lo contrario con la misma solidez: lo escrito está escrito, para siempre y sin apelación, con independencia de la red y de la supervivencia del proveedor. Lo que no puede prometer es ninguna invariante que exija observar simultáneamente escrituras que ocurren en dispositivos incomunicados; no por falta de ingenio, sino porque exigirlo equivale a reintroducir coordinación y con ella al árbitro. Se puede recuperar caso por caso —reservando rangos de identificadores por adelantado, o exigiendo confirmación central solo para las operaciones críticas—, y cada una de esas recuperaciones es un préstamo de la primera posición con sus intereses.

La convergencia sin árbitro promete lo que ninguna de las otras dos: acuerdo garantizado entre réplicas sin ninguna comunicación previa ni ningún punto especial. Es la promesa más fuerte en disponibilidad y la más débil en semántica. Sirve espléndidamente allí donde la intención del usuario es acumulativa y todo aporte es válido, y sirve mal allí donde hay reglas que un resultado puede violar.

Las tres se pueden combinar por capas, y esa es la forma más común en la práctica. Un sistema puede converger para el estado de trabajo, apoyarse en la irrevocabilidad local para la durabilidad de lo escrito y reservar un árbitro para el pequeño conjunto de operaciones críticas que lo necesitan. Lo importante es que la reserva sea explícita y acotada: cada operación que se manda al árbitro reintroduce el requisito de conectividad para esa operación concreta, y por tanto reintroduce una ruleta de carga y una posible reversión. Contar cuántas operaciones caen en esa categoría es una buena medida de cuánta soberanía real ofrece un producto.

Léela como un menú de renuncias y no de ventajas. La columna de la derecha es la que decide, porque es la que un equipo descubre demasiado tarde cuando eligió por la columna del medio. Y obsérvese que las tres renuncias son de naturaleza distinta: una es de experiencia, otra es de expresividad y la tercera es de semántica. No se pueden comparar en una sola escala, y esa incomparabilidad es exactamente lo que impide que exista una posición ganadora.