Cierre: el mapa completo, qué construir ahora y la pregunta final

Cincuenta y ocho niveles después, conviene detenerse a mirar el terreno desde arriba una última vez. Lo que empezó con un artículo de 2019 que diagnosticaba un compromiso mal aceptado por la industria termina en un conjunto de técnicas maduras, un puñado de problemas abiertos con nombre propio y, sobre todo, una forma distinta de mirar cualquier sistema. Esa forma de mirar es lo único que de verdad se lleva uno de un recorrido largo: los detalles se olvidan y se vuelven a consultar, pero el conjunto de preguntas que uno aprende a hacer se queda. Esta última lección hace tres cosas: pone el mapa completo en una vista, propone tres construcciones concretas para que lo aprendido no se evapore, y deja una sola pregunta que sigue funcionando cuando todas las herramientas de este track hayan sido sustituidas por otras.

El territorio recorrido, de una sola vista

El track tiene cinco movimientos y ninguno es prescindible, porque cada uno responde a una pregunta que el anterior abrió.

El primero son los principios, del nivel uno al cinco: los siete ideales, la distinción entre local-first y offline-first, el coste real de la arquitectura cliente-servidor, la propiedad del dato y, sobre todo, el criterio inverso de cuándo no hacerlo, que es el nivel más maduro de ese bloque. El segundo es la máquina, del seis al diecinueve: todo lo que el navegador ofrece para guardar datos, de los cinco megabytes de localStorage a SQLite compilado a WebAssembly sobre el sistema de ficheros del origen, con las cuotas, el desalojo, los hilos, los bloqueos y la elección de líder entre pestañas. Ese bloque es el que responde si esto es posible.

El tercero es la convergencia, del veinte al cuarenta y cuatro, y es el corazón del recorrido: por qué sincronizar es difícil, por qué el tiempo del sistema no sirve para ordenar eventos, qué es exactamente un conflicto, el teorema que sostiene los tipos replicados, la familia entera de contadores, conjuntos, registros, mapas y secuencias, el fallo de intercalación que nadie vio durante décadas, las implementaciones que uno escribe a mano para entenderlas, las bibliotecas reales y el problema del historial que no deja de crecer. El cuarto es el sustrato, del cuarenta y cinco al cincuenta y tres: el hash como identidad, los grafos de Merkle, Git leído como almacén direccionado por contenido, la reconciliación eficiente, los transportes entre iguales y el mapa de los motores de sincronización. Y el quinto es la frontera, del cincuenta y cuatro al cincuenta y siete: identidad sin servidor, cifrado extremo a extremo sobre datos que convergen, migración de esquema y casos de estudio de quienes ya lo hacen en producción.

flowchart TD
P[1 a 5 Principios] --> M[6 a 19 La maquina]
M --> C[20 a 44 La convergencia]
C --> S[45 a 53 El sustrato]
S --> F[54 a 57 La frontera]
F --> D[58 Sintesis]
P --> D
style D fill:#a6e3a1,color:#11111b
style C fill:#89b4fa,color:#11111b

Tres construcciones que consolidan el track

Leer no basta y este campo lo castiga más que otros, porque sus errores no se manifiestan en el desarrollo sino meses después y con dos dispositivos de por medio. Estas tres construcciones están ordenadas por esfuerzo y cada una fija una parte distinta de lo aprendido.

La primera es un editor de notas para una sola persona con varios dispositivos. Suena modesto y no lo es: obliga a montar el almacén local en un worker, a decidir la unidad de sincronización, a elegir motor de convergencia, a implementar el arranque en frío y a enfrentarse al primer conflicto real cuando editas la misma nota en el móvil y en el portátil sin red. Es el proyecto que más aprendizaje entrega por hora invertida.

La segunda es reimplementar un tipo replicado desde cero con sus pruebas basadas en propiedades, sin mirar la biblioteca que ya lo hace. Una secuencia es el ejercicio completo, pero un conjunto con lápidas ya obliga a razonar sobre concurrencia real. Lo valioso no es el código, que nunca usarás: es que al generar historias concurrentes aleatorias y comprobar convergencia descubres a mano las propiedades que hasta entonces eran una frase de una lección.

La tercera, la más ambiciosa y la que separa a quien ha entendido el track de quien lo ha leído, es un producto pequeño con dos regímenes conviviendo: un puñado de entidades con autoridad central y transacciones clásicas, y el resto del modelo replicado y convergente, con la frontera entre ambos documentada y defendida. Casi nadie construye esto en un ejercicio y es exactamente lo que un producto real necesita.

La pregunta con la que conviene quedarse

Todo lo anterior caduca. Las bibliotecas se sustituyen, los formatos cambian, los motores que hoy están en su versión 1.0 tendrán sucesores, y una parte de los problemas abiertos tendrá respuestas parciales que hoy no se pueden anticipar. Lo que no caduca es una pregunta, y conviene enunciarla con precisión porque su formulación exacta es lo que la hace útil.

Qué fracción de este sistema necesita que alguien diga que sí, y qué se paga por esa fracción.

Es una sola pregunta con dos mitades y ninguna funciona sin la otra. La primera mitad obliga a inventariar, entidad por entidad, qué operaciones exigen un punto único capaz de aceptar o rechazar antes de que se consideren ocurridas, y la respuesta casi nunca es todo ni nada. La segunda mitad obliga a nombrar el precio de esa fracción en las cuatro monedas en las que se paga siempre: latencia, disponibilidad, privacidad y permanencia. Un equipo que responde las dos mitades por escrito ha hecho el trabajo de arquitectura; uno que responde solo la primera ha hecho un diagrama.

Lo interesante es que la pregunta no es específica de local-first ni deja de funcionar fuera de este campo. Aplicada a una arquitectura de microservicios, revela qué acoplamientos son necesarios y cuáles son heredados. Aplicada a un motor de sincronización comercial, revela dónde han puesto de verdad la autoridad por debajo del vocabulario de la página de inicio. Aplicada a un sistema con un servidor grande y sano, puede dar la respuesta perfectamente legítima de que casi todo necesita arbitraje y que el precio merece la pena. Esa también es una buena respuesta, y saber llegar a ella con argumentos es parte de lo que este track intentaba enseñar.