Lo que se repite en los cuatro: la lectura transversal del nivel

Cuatro casos no son una muestra estadística, pero sí son suficientes para notar cuándo algo se repite sin que nadie se haya puesto de acuerdo. Un gestor de incidencias con su contador global, un editor colaborativo con dos canales de propiedades opuestas, un cuaderno de notas cuya fuente de verdad es una carpeta del disco y un lienzo de diseño que declara por escrito tener un árbitro central son, sobre el papel, cuatro arquitecturas incompatibles entre sí. Y sin embargo, al ponerlas en fila aparecen cuatro coincidencias que ninguna de las cuatro presenta como decisión de diseño y que las cuatro tomaron igual. Esta lección cierra el nivel extrayendo esas coincidencias, con el mismo cuidado de fuentes que abrió la primera lección: lo documentado por cada equipo, lo reconstruido por terceros y lo que es inferencia mía. La conclusión no es un catálogo más, es un método de lectura que se puede aplicar mañana a cualquier producto, incluido el propio.

El servidor cambia de oficio pero no se marcha

El primer rasgo es el más incómodo para la versión divulgativa del movimiento. En los cuatro casos hay un servidor, en los cuatro hace menos que en una arquitectura clásica, y en ninguno de los cuatro desaparece. Lo que cambia entre ellos es el oficio, no la existencia. En el gestor de incidencias el servidor ejecuta las transacciones, incrementa un contador global que funciona como número de versión de toda la base y filtra los paquetes de deltas contra la suscripción de cada cliente. En el editor colaborativo le quedan cuatro trabajos —retransmitir, persistir, autorizar y avisar de que algo cambió— y ninguno de ellos es fusionar. En el lienzo de diseño el papel está declarado con todas las letras por el propio equipo: el servidor es la autoridad central y define el orden de los sucesos, y esa declaración es justo lo que les permitió simplificar el diseño.

Puestos en fila, los oficios que aparecen se dejan agrupar en cuatro, y esa taxonomía sirve para leer cualquier producto ajeno en un minuto. Está el árbitro, que decide el orden de los sucesos y por tanto quién gana un choque. Está el repetidor, que entrega a otros lo que uno escribe y no interpreta nada de lo que pasa por él. Está el buzón, que guarda para quien no estaba conectado y lo entrega cuando aparezca. Y está la bóveda, que conserva de forma duradera y replicada lo que un dispositivo no sabe conservar. Los cuatro casos del nivel reparten esos oficios de forma distinta, y ninguno de los cuatro se queda con menos de dos.

Fíjate en que esos cuatro oficios se distinguen por una propiedad clara: solo el primero necesita entender algo del contenido para hacer su trabajo. Repetir, guardar para después y conservar de forma duradera son funciones que operan sobre sobres opacos, y por eso conviven sin problema con el cifrado que ocupó el nivel anterior. Arbitrar es la excepción, porque decidir quién gana exige saber qué hay dentro o, como mínimo, imponer un orden que todos acaten. Inferencia mía: de ahí que el caso que declara tener árbitro sea también el que menos habla de cifrado y el que más funciones de servidor conserva, y que el que más se acerca a la propiedad total del dato sea el que no arbitra nada.

El cuarto caso es el interesante porque es el que más se acerca a prescindir del servidor y aun así no prescinde. Un cuaderno cuya fuente de verdad es una carpeta del disco funciona entero sin conexión y sin cuenta, y sin embargo la empresa vende una bóveda remota de pago con sus planes, sus topes de tamaño y su historial de versiones. El servidor pasó de ser infraestructura obligatoria a ser producto opcional, que es la reducción de papel más radical de las cuatro, y ni siquiera ahí llega a cero.

flowchart TB
A[gestor de incidencias] --> S[el servidor sigue existiendo]
B[editor colaborativo] --> S
C[cuaderno de notas] --> S
D[lienzo de diseno] --> S
S --> J1[ordenar y filtrar la entrega]
S --> J2[retransmitir persistir y avisar]
S --> J3[custodiar la boveda remota de pago]
S --> J4[arbitrar el orden de los sucesos]
S --> P[autorizar quien puede ver que]
style P fill:#f38ba8,color:#11111b

Conviene decir también qué oficio sí se marchó, porque si no la conclusión suena a que nada cambió. El trabajo que abandona el servidor en estos casos es fusionar el contenido, que era el más caro de todos y el que obligaba a preguntar antes de pintar. Ese abandono es un cambio enorme respecto al modelo clásico y es la causa directa de la sensación de inmediatez. Lo que este primer rasgo señala, entonces, no es que la reducción sea falsa, sino que tiene un suelo, y ese suelo es el nodo rojo del diagrama.

Merece la pena preguntarse por qué la autorización es tan resistente, porque la respuesta explica la forma de los cuatro. Un permiso comprobado únicamente en el cliente es una convención: funciona mientras todo el mundo ejecute el programa oficial, y deja de funcionar ante el primero que no lo haga. Para que sea un control de verdad sin servidor haría falta que el dato estuviera cifrado con una clave que el no autorizado no tenga, lo cual convierte el asunto entero en gestión de claves de grupo, que es la materia del nivel anterior y sigue siendo terreno de investigación más que de bibliotecas listas para producción. Ninguno de los cuatro equipos entró ahí, y esa es la explicación más simple y probablemente la correcta de por qué los cuatro conservaron un servidor con potestad sobre quién ve qué.

Y ahí está la observación que sostiene la lección entera. Las cuatro funciones de arriba del diagrama se reparten de forma desigual: cada caso tiene unas y no tiene otras. La de abajo la tienen los cuatro. La autorización es la única responsabilidad que ninguno de los cuatro equipos logró mover al cliente, y en el caso mejor documentado esa imposibilidad llega a producir una partición explícita del producto: el sistema multijugador se usa solo para los documentos, mientras que comentarios, usuarios, equipos y proyectos viven en una base de datos relacional y se sincronizan con un sistema completamente distinto, con compromisos distintos en rendimiento, disponibilidad sin conexión y seguridad. Inferencia mía: que esto ocurra en los cuatro sugiere que no es una casualidad de calendario ni una deuda técnica pendiente, sino la consecuencia de que un permiso comprobado únicamente en el cliente no es un permiso.

Nadie baja todo: el alcance lo acota alguien a mano

El segundo rasgo es igual de constante y aún menos anunciado. En ninguno de los cuatro casos el cliente se descarga el corpus completo, y en los cuatro el recorte es una decisión deliberada que alguien tomó y escribió, no un efecto secundario de la implementación. El gestor de incidencias declara una estrategia de carga por modelo —cargar en el arranque, cargar entera bajo demanda, cargar por subconjuntos, cargar solo si alguien lo pide, no salir nunca del cliente— y encima de eso filtra por grupos de sincronización. En el editor colaborativo con modo sin conexión, es el propio usuario quien marca qué páginas quiere disponibles, y esa marca es literalmente el alcance. En el cuaderno de notas el alcance es la carpeta, con sincronización selectiva por tipo de fichero, exclusión de carpetas y topes explícitos de tamaño por fichero y por bóveda. Y en el lienzo de diseño la unidad es el documento: al volver de una desconexión larga, el cliente descarga una copia nueva del documento y reaplica encima lo editado sin conexión.

La cuarta columna de la tabla anticipa el rasgo siguiente y conviene mirarla desde ya, porque contiene la sorpresa de la lección. Ninguna de esas cuatro celdas dice fusión, resolución de conflictos ni estructura convergente. Las cuatro hablan de qué se descarga, de qué se publica, de qué garantías da el almacén local y de cómo se parte el producto. Esa es la evidencia, débil pero constante, sobre la que se apoya la sección que viene.

El alcance acotado no sale gratis, y conviene enumerar lo que cuesta porque en las presentaciones nunca aparece. Todo lo que queda fuera del subconjunto deja de estar disponible con las propiedades del subconjunto: la búsqueda global sobre el corpus entero vuelve a ser una petición al servidor, los informes que cruzan varios documentos vuelven a serlo, y las funciones que necesitan mirar todo a la vez —detección de duplicados, referencias cruzadas, estadísticas de organización— se quedan del lado remoto o no existen. Inferencia mía: eso explica que las herramientas de esta familia tengan búsquedas locales excelentes dentro de su ámbito y sorprendentemente pobres fuera de él, y que ninguna de las cuatro presuma de análisis agregado. El alcance no solo decide qué se descarga, decide qué funciones puede tener el producto, que es la misma conclusión a la que llegaba el nivel del cifrado por un camino completamente distinto.

Merece la pena fijarse en un detalle de la segunda columna que cambia la experiencia del producto. En tres de los cuatro casos el alcance es visible para el usuario: se marca una página, se excluye una carpeta, se abre un documento. En el cuarto es invisible, porque los grupos de sincronización viven en el servidor y nadie los enseña. Inferencia mía: el alcance invisible es el que produce el techo descrito en la primera lección, porque cuando el subconjunto deja de caber no hay ninguna palanca que el usuario pueda mover y la degradación tiene que hacerla el equipo, entidad por entidad, sin que nadie fuera se entere.

De ahí sale una recomendación que este nivel puede permitirse dar porque tiene cuatro casos detrás: si el alcance de tu producto va a ser invisible, dale al menos una salida de emergencia visible. Un ajuste que permita reducir el ámbito, un indicador de cuánto ocupa lo que se ha traído, una manera de expulsar del dispositivo un proyecto que ya no se toca. No hace falta convertirlo en una funcionalidad destacada; basta con que exista, porque el día en que un cliente crezca por encima de lo previsto la alternativa es que su producto se degrade sin que él pueda hacer nada y sin que sepa por qué.

Y hay una propiedad que comparten las cuatro unidades de la tercera columna y que conviene extraer, porque es la que hace utilizable esta decisión. El subconjunto suscrito por equipos, el documento, la página marcada y la carpeta son todas cosas que el usuario ya sabe nombrar antes de que ningún ingeniero se lo explique. Ninguno de los cuatro eligió como unidad de replicación un tramo de la base de datos, una partición por identificador ni un umbral de tamaño, que serían las opciones naturales si la decisión se hubiera tomado mirando el almacenamiento. Inferencia mía: la unidad de replicación funciona cuando coincide con una unidad mental del dominio, porque solo entonces el usuario puede razonar sobre qué tiene disponible y qué no, y ese es el requisito real que descarta las particiones técnicamente elegantes.

Lo difícil nunca fue la convergencia

El tercer rasgo es el que más contradice la expectativa con la que casi todo el mundo entra en este campo. Si uno mira dónde se fue el esfuerzo de ingeniería que estos equipos consideraron digno de contar, la convergencia aparece resuelta, comprada o directamente esquivada. El lienzo de diseño declara que no usa un tipo replicado sin conflictos de verdad, sino una estructura inspirada en varios, y explica que pudieron retirar esa sobrecarga porque tienen árbitro. El editor colaborativo usa una biblioteca abierta para el documento y un protocolo de presencia deliberadamente pobre para los cursores. El gestor de incidencias resuelve los choques con la última escritura y sin reloj alguno, porque el orden lo fija quien recibe. Y el cuaderno de notas ni se plantea el problema, porque su unidad es un fichero y su modelo de colaboración concurrente es, honestamente, malo.

Frente a eso, lo que sí ocupa páginas enteras en las fuentes primarias son otras dos cosas. La primera es la entrega y los permisos: el filtro de suscripción que resulta ser el mismo filtro que el de autorización, el mecanismo de aviso basado en empuje que sustituyó al sondeo porque el sondeo no escalaba a millones de dispositivos, la partición del producto en dos sistemas de sincronización con garantías distintas, y la sección de límites donde una empresa documenta qué metadatos necesita leer su servidor para enrutar, deduplicar y versionar, incluida la ausencia de vínculo criptográfico entre la ruta y el contenido.

Hay una explicación estructural para ese reparto y conviene enunciarla. La convergencia es un problema cerrado: se puede definir con precisión matemática, se puede probar con pares de réplicas y un algoritmo correcto lo es para cualquier producto que lo use, razón por la cual existe como biblioteca. Los permisos y las migraciones no admiten ese empaquetado, porque dependen del modelo de datos concreto, de la política concreta de la organización y del historial concreto de versiones que ese producto haya publicado. Nadie puede escribir la biblioteca de permisos de tu producto, y por eso ese trabajo aparece íntegro en cada uno de los cuatro casos mientras la convergencia se despacha citando una dependencia.

Conviene notar de paso que esa asimetría explica también la forma de la literatura del campo. Los artículos académicos hablan casi siempre de convergencia, porque es la parte formalizable y la que admite demostraciones; los artículos de ingeniería de producto hablan casi siempre de entrega, permisos y migración, porque es la parte que les rompió algo un martes. Leer solo la primera mitad de esa bibliografía produce una idea muy incompleta de en qué consiste construir uno de estos sistemas.

La segunda es la migración, y aparece en los cuatro con formas distintas. Un producto en marcha tuvo que convertir su base local de caché de mejor esfuerzo, sin garantías sobre qué registros estarían disponibles ni durante cuánto tiempo, en una capa de almacenamiento persistente con garantías, y además migrar dinámicamente al modelo convergente las páginas marcadas como disponibles sin conexión, lo que implica que la aplicación convive con dos representaciones del mismo contenido. Otro publicó una especificación abierta con licencia MIT para un formato nuevo, que es la forma que toma la migración cuando el horizonte no son dos versiones sino décadas. Inferencia mía: el patrón que emerge es que la convergencia es un problema con soluciones empaquetables y las otras dos no lo son, porque dependen del modelo de datos concreto y de la política concreta de cada producto.

Conviene subrayar un detalle de esos relatos de migración que suele pasar desapercibido: en varios de los casos lo que cambió fue una capa fundacional, no una funcionalidad. Convertir el almacén local de caché sin garantías en capa persistente con garantías es documentado por el propio equipo y no es un retoque, es cambiar el suelo sobre el que se apoya todo lo demás. Publicar una especificación abierta para un formato nuevo también lo es, en la escala de las décadas. Y el reparto de estrategias de carga por modelo que aparece en el caso reconstruido tiene toda la pinta de haber crecido con la escala, aunque eso ya es inferencia mía y no debe leerse como una afirmación sobre lo que ese equipo hizo ni cuándo. La lectura prudente es que estas arquitecturas no se acaban de diseñar en el primer intento y que sus autores lo cuentan cuando lo cuentan.

Hay un motivo de calendario que explica por qué esta desproporción sorprende tanto a quien empieza. La convergencia es el problema del primer mes: se nota en el prototipo, se demuestra con dos pestañas abiertas y produce una demostración vistosa. Los permisos y las migraciones son problemas del segundo año, porque no existen mientras no hay organizaciones con altas y bajas ni versiones antiguas instaladas en dispositivos reales. Cuando aparecen, el coste de rediseñar el modelo de datos está en su punto máximo, y de ahí sale el patrón que los cuatro casos dejan ver de refilón: los artículos de ingeniería que estos equipos publican son casi siempre relatos de cómo arreglaron a posteriori algo que en el prototipo no era un problema.

La consecuencia práctica para quien está decidiendo hoy es bastante concreta y va contra el instinto de la mayoría de los equipos técnicos. La convergencia conviene comprarla: usar una biblioteca madura, aceptar sus decisiones y no escribir una propia salvo que el producto tenga una razón tan específica como la que declaró el lienzo de diseño para no usar tipos replicados de verdad. El presupuesto de ingeniería que eso libera hay que gastarlo en las dos partidas que nadie puede venderte hechas: el modelo de permisos, con su filtro de entrega, y la política de versionado que va a permitir que dentro de tres años una versión antigua conviva con la nueva sin destruir nada. Es un reparto de esfuerzo que suena aburrido en una reunión y que es exactamente el que hicieron los cuatro.

El producto decide la arquitectura, y esa es la lectura del nivel

El cuarto rasgo es el que ordena a los otros tres, y en los cuatro casos aparece explícito en las fuentes. El lienzo de diseño justifica que editar simultáneamente el mismo texto no funcione con un argumento que no es técnico: es una herramienta de diseño, no un editor de texto, y ese caso de uso no está entre los que optimizan. El cuaderno de notas parte de una tesis publicada sobre ficheros que duran más que las aplicaciones, y de ahí se siguen el formato abierto, la ausencia de base de datos propietaria y también la mala colaboración concurrente. El editor colaborativo construyó el modo sin conexión porque llevaba años siendo lo más pedido, y esa demanda es la que obligó a la migración del almacén. Y el gestor de incidencias promete latencia percibida nula, promesa que solo es sostenible si existe un subconjunto acotado que cubra casi todas las preguntas del usuario.

Conviene notar además que las cuatro promesas se contradicen entre sí, y esa es la prueba de que no hay una arquitectura óptima esperando a ser descubierta. Prometer ficheros que duren sesenta años obliga a un formato sin dependencias ocultas, y un formato así no admite la maquinaria de convergencia que hace falta para editar a doce manos. Prometer edición simultánea de calidad obliga a esa maquinaria, y sostenerla resulta mucho más barato con un árbitro que sin él. Prometer respuesta instantánea sobre un modelo relacional obliga a acotar el subconjunto, lo cual pone un techo al tamaño de la organización que puede usar el producto. Las tres promesas son legítimas, las tres tienen su producto, y ninguna combinación de ingenio permite cumplir las tres a la vez.

Ninguna de esas cuatro frases es una decisión de ingeniería, y las cuatro determinan por completo la arquitectura que hay debajo. Esa es la lectura transversal con la que conviene cerrar el nivel: no existe la arquitectura local-first correcta a la que los productos deberían converger, existen cuatro productos con promesas distintas cuyas arquitecturas son distintas por eso mismo. Quien empieza eligiendo estructura de datos está respondiendo la pregunta en el orden equivocado, y lo notará el día en que descubra que su motor de convergencia funciona perfectamente y su modelo de permisos no se sostiene.

Puestos sobre el eje de la autoridad que definió el nivel 2, los cuatro se ordenan además de una forma que aclara el mapa. El lienzo de diseño está en el extremo de la autoridad central declarada, con una copia local que es un caché de trabajo excelente y una reincorporación que pasa por descargar la verdad de fuera. El gestor de incidencias está muy cerca, porque su contador global es una autoridad tan real como la anterior aunque se anuncie menos. El editor colaborativo ocupa la franja intermedia, con contenido que converge en el cliente y una capa de coordinación que sigue siendo del servidor. Y el cuaderno de notas está en el otro extremo, con la fuente de verdad en el disco del usuario y el servidor convertido en accesorio de pago. Inferencia mía: la posición en ese eje predice bastante bien la calidad de la colaboración concurrente de cada uno, y lo hace en sentido inverso, de modo que los dos que mejor colaboran son los dos que más autoridad conservan. No es una casualidad simpática: es el precio del árbitro cobrado al revés.

// La ficha que conviene rellenar antes de elegir ninguna tecnica
const lectura = {
  servidor: 'que sigue haciendo cuando el cliente ya tiene el dato',
  unidad:   'que se replica exactamente y quien decidio su tamano',
  esfuerzo: 'donde se fue el trabajo que el equipo considero digno de contar',
  origen:   'que promesa de producto vino antes que la decision tecnica'
};

Conviene además fijar el orden correcto de esas cuatro preguntas, porque no son intercambiables. La cuarta manda sobre las demás: la promesa de producto determina qué operaciones deben funcionar solas, eso determina la unidad que hay que replicar, la unidad determina cuánto le queda por hacer al servidor y todo junto determina dónde va a irse el esfuerzo del equipo. Recorrerlas en ese orden convierte una discusión de arquitectura en una cadena de consecuencias; recorrerlas al revés, que es como se hacen casi siempre, convierte una elección de biblioteca en una promesa que nadie revisó. Los cuatro casos de este nivel son, leídos así, cuatro recorridos completos de esa cadena, y su valor didáctico está menos en las técnicas concretas que en poder ver la cadena entera de cada uno.

Existe una quinta coincidencia que no he puesto en la lista porque es tan universal que ya no informa, y aun así conviene nombrarla para cerrar el inventario: en los cuatro casos el cambio local se aplica de inmediato, sin esperar confirmación de nadie. En el gestor de incidencias la escritura toca el modelo en memoria antes de encolarse; en el lienzo de diseño se aplica sin esperar al servidor y de ahí sale todo el trabajo de evitar el parpadeo; en el editor colaborativo es la premisa de la estructura convergente; y en el cuaderno de notas ni siquiera hay a quién esperar. Esa inmediatez es la única propiedad que los cuatro comparten sin matices, y es la que el usuario percibe como calidad. Todo lo demás que hemos enumerado —el servidor, el alcance, los permisos, las migraciones— es el precio de sostenerla.

Hay que decir además que estos cuatro casos no agotan el espacio, y quien construya algo cuya promesa no encaje en ninguno de ellos no debería forzar el parecido. Un producto de escritura personal con colaboración ocasional, una herramienta de campo que pasa días enteros sin cobertura, un sistema con requisitos de auditoría, un editor de datos científicos con corpus que no caben: ninguno se corresponde limpiamente con los cuatro casos, y sus arquitecturas correctas serán distintas. Lo transferible del nivel no es el catálogo sino el orden de las preguntas, y ese sí funciona para un producto que no se parezca a nada de lo publicado, que es justamente la situación en la que uno agradece tener un método en lugar de un ejemplo.

Si hubiera que resumir el nivel en una sola frase para alguien que no va a leerlo entero, sería esta: los cuatro productos que mejor han contado cómo funcionan comparten un servidor que no se marcha, un alcance que alguien acotó a mano, un esfuerzo que se fue a permisos y migraciones, y una promesa de producto que llegó antes que cualquier decisión técnica. No hay nada en esa frase sobre estructuras de datos, y esa ausencia es deliberada, porque las estructuras de datos son la parte de este campo que mejor está resuelta y la que menos decide el resultado. Un equipo puede equivocarse eligiendo motor de convergencia y recuperarse; equivocarse en el alcance o en el modelo de permisos suele obligar a rehacer el producto.

Queda una observación final que este nivel debe dejar dicha y que enlaza con lo que viene después. Ninguno de los cuatro casos es el sistema del manifiesto: no hay entre ellos un producto entre pares, sin servidor, con permisos descentralizados y con propiedad completa del dato en todos sus planos. El más puro en propiedad colabora mal; el mejor colaborando declara tener autoridad central; el más rápido depende de un contador global; y el que mejor documenta sus límites documenta precisamente los que no puede cerrar. Eso no invalida el ideal: mide la distancia entre el ideal y lo que hoy sabe construir la industria, y esa distancia tiene nombres propios que el siguiente nivel enumera uno a uno.