El origen: la investigación que precede a la biblioteca

Casi todas las bibliotecas de sincronización que has visto hasta aquí nacieron de una necesidad de producto: alguien tenía una aplicación que fallaba al reconectar y escribió el código que hacía falta para que dejara de fallar. Automerge nació al revés. Primero hubo una pregunta de investigación —si es posible definir un tipo de dato JSON replicado cuya fusión converja de forma demostrable sea cual sea el orden en que lleguen los cambios— y solo después, cuando la respuesta estuvo escrita y revisada, alguien se sentó a diseñar una API. Ese orden de los factores no es una anécdota biográfica: es la causa directa de todo lo que la biblioteca hace bien y de casi todo lo que hace mal. Explica por qué guarda la historia entera aunque cueste, por qué su modelo de datos es deliberadamente pobre, por qué tardó años en ser rápida y por qué, cuando por fin lo fue, no tuvo que romper el formato. Esta lección reconstruye esa genealogía y extrae de ella las prioridades que gobiernan el resto del nivel.

La genealogía de una biblioteca

La pregunta que da origen al proyecto es más estrecha y más ambiciosa de lo que parece. No es «cómo sincronizo dos clientes», que es un problema de ingeniería con mil respuestas parciales, sino «cómo defino un tipo de dato con la forma de un objeto JSON —mapas anidados, listas, texto, contadores— tal que dos réplicas que hayan recibido el mismo conjunto de operaciones estén garantizadamente en el mismo estado, sin coordinación previa, sin árbitro y sin que importe el orden de llegada». Es una pregunta de teoría de sistemas distribuidos, y su respuesta es un teorema, no un programa.

Ese linaje académico —ligado a la investigación de Martin Kleppmann y al trabajo posterior del laboratorio Ink and Switch, el mismo entorno del que salió el término local-first que abrió este track— deja una huella reconocible. La implementación de referencia existió antes que cualquier caso de uso serio, y durante bastante tiempo fue lenta y consumía una barbaridad de memoria. En un proyecto nacido de un producto, eso lo habría matado; aquí no, porque el criterio de éxito no era la latencia sino la propiedad. Una biblioteca que va rápido pero diverge está rota de una forma que no se arregla, mientras que una biblioteca que converge pero va lenta está incompleta de una forma que sí se arregla, y la historia posterior del proyecto es exactamente la crónica de ese arreglo.

Conviene además situar el término CRDT con algo más de precisión que la habitual, porque nombra una familia y no una técnica. Un tipo de dato replicado sin conflicto es cualquier estructura cuya operación de combinación cumple ciertas propiedades algebraicas, y hay dos maneras clásicas de conseguirlo: transmitir estados y combinarlos con una función que sea un supremo, o transmitir operaciones y garantizar que su aplicación es conmutativa. Automerge pertenece de lleno a la segunda familia y lleva esa elección hasta el final, porque transmitir el estado completo de un documento con historia sería absurdo. La consecuencia es que todo el diseño gira en torno a identificar operaciones y a saber cuáles ocurrieron antes que cuáles, que es justo lo que ocupará las lecciones siguientes.

flowchart TD
A[pregunta de investigacion] --> B[definir un tipo de dato JSON replicado]
B --> C[demostrar convergencia para todo orden de llegada]
C --> D[implementacion de referencia lenta]
D --> E[reescritura en Rust y compilacion a WebAssembly]
E --> F[la ergonomia de la API llega al final]
style C fill:#a6e3a1,color:#11111b
style F fill:#89b4fa,color:#11111b

Conviene señalar la asimetría de esa cadena porque es la lección transferible. Las propiedades que se demuestran al principio son gratis para siempre: ninguna optimización posterior las puso en riesgo, y por eso la versión 3 pudo reescribir la representación interna entera sin romper el formato de archivo ni la semántica de fusión. Las propiedades que se dejan para después —velocidad, memoria, tamaño— son negociables y se pueden comprar con trabajo de ingeniería. Elegir en qué lado de esa línea pones cada requisito es, en la práctica, la decisión de arquitectura más consecuente que se toma en un proyecto de este tipo.

Qué significa corrección demostrable

El término se usa con ligereza, así que conviene fijarlo. Una biblioteca bien probada te dice que en los casos que alguien pensó en probar no se observó divergencia. Una biblioteca con corrección demostrable te dice algo categóricamente distinto: que existe un argumento matemático de que la divergencia es imposible para todo el espacio de entradas, incluidas las que nadie ha imaginado todavía.

La propiedad concreta se llama consistencia eventual fuerte y tiene dos mitades que se citan por separado con demasiada frecuencia. La primera es que si dos réplicas han recibido el mismo conjunto de cambios, sus estados son idénticos. La segunda, más silenciosa, es que la fusión no puede fallar: no hay ninguna combinación de cambios que produzca un error, un bloqueo o una petición de intervención humana. Juntas garantizan que el sistema siempre tiene una respuesta y que esa respuesta es la misma en todas partes.

Esa segunda mitad es la que ahorra más código del que nadie estima. En una arquitectura de sincronización artesanal, buena parte del trabajo no está en fusionar sino en gestionar los casos en que la fusión no se puede resolver: colas de reintento, estados de conflicto pendientes, pantallas donde se le pide al usuario que elija, marcas de registro roto que alguien tendrá que limpiar a mano. Toda esa maquinaria existe porque la operación de combinación es parcial, es decir, porque hay entradas para las que no está definida. Cuando la operación es total, la maquinaria entera desaparece de golpe, y con ella desaparece también la clase de incidentes en producción más difícil de reproducir: los que dependen de un orden de llegada concreto que nadie sabe recrear.

// Las tres propiedades algebraicas que sostienen la garantia.
// Se enuncian sobre la operacion de fusion de dos documentos.

// 1. Conmutativa: el orden de llegada es irrelevante.
merge(a, b) === merge(b, a)

// 2. Asociativa: el agrupamiento de los cambios es irrelevante.
merge(merge(a, b), c) === merge(a, merge(b, c))

// 3. Idempotente: recibir dos veces lo mismo no cambia nada.
merge(a, a) === a

Esas tres líneas son el motivo por el que un sistema construido sobre Automerge no necesita un servidor autoritativo, ni un protocolo de consenso, ni relojes sincronizados. Si la fusión es conmutativa, asociativa e idempotente, entonces cualquier topología de red vale: estrella con servidor, malla entre pares, sincronización por correo electrónico o por una memoria USB que alguien lleva andando de una oficina a otra. La red deja de ser parte del argumento de corrección y pasa a ser un simple detalle de transporte, que es justamente lo que un track de local-first necesita.

Vale la pena insistir en lo poco frecuente que es esta situación. En la inmensa mayoría de arquitecturas distribuidas, la corrección depende de propiedades del transporte: que los mensajes lleguen, que lleguen una sola vez, que lleguen en orden, o que exista un canal fiable hacia un nodo concreto. Cada una de esas suposiciones es una fuente de incidentes cuando la red se comporta como se comporta de verdad. Aquí ninguna de ellas aparece en el argumento: el transporte puede duplicar, reordenar, perder y retrasar cuanto quiera, y lo único que eso afecta es cuándo converge el sistema, nunca si converge. Esa separación limpia entre garantías de seguridad y garantías de progreso es la marca de un diseño que ha pasado por una demostración.

La historia completa como decisión fundacional

La segunda herencia es la que más consecuencias prácticas tiene. Para que la fusión funcione sin coordinación, cada réplica necesita poder situar cualquier cambio entrante respecto de los que ya conoce, y eso exige conservar la identidad y las dependencias causales de cada operación. No es una elección de diseño que se pueda revocar: es un requisito del mecanismo. Guardar la historia no es una funcionalidad de Automerge, es su condición de posibilidad.

La consecuencia es la analogía que la propia documentación usa y que conviene tomarse en serio: un documento de Automerge es, a la vez, un objeto JSON y un repositorio de control de versiones. Tiene un valor actual que lees como leerías cualquier estructura de datos, y tiene un historial de commits con sus padres causales que puedes recorrer. Ambas cosas viven en el mismo archivo binario y son inseparables.

// Un documento es a la vez un valor que se lee...
console.log(doc.titulo, doc.tareas.length);

// ...y un grafo de cambios que se recorre.
// Cada cambio conoce a sus padres, igual que un commit.
//
//   raiz ---- cambio de ana ----\
//      \                         >--- fusion --- cabeza
//       \--- cambio de luis ----/
//
// Ese grafo es lo que permite fusionar sin arbitro:
// la relacion de dependencia entre cambios ya codifica
// que ocurrio antes que que, sin necesidad de reloj alguno.

La analogía con el control de versiones es literal en un punto que conviene subrayar: la identidad de un cambio es el hash de su contenido y de sus padres, exactamente igual que en un repositorio de código. Eso trae de regalo dos propiedades muy útiles. La primera es la deduplicación automática, porque el mismo cambio producido dos veces da el mismo hash y la segunda copia se ignora sola. La segunda es la verificación de integridad, porque no se puede alterar un cambio del pasado sin invalidar el hash de todos sus descendientes.

La cuarta tarjeta es la que define la agenda de los tres niveles siguientes. Un documento que registra cada pulsación acumula metadatos sin techo, y durante la serie 2.x esa acumulación era un problema real: documentos grandes que consumían cientos de megabytes al abrirse, y algunos que sencillamente no llegaban a abrirse. La lección cuarta cuenta cómo la versión 3 desarma ese problema sin renunciar a nada de lo anterior, y por qué eso solo fue posible gracias a que la corrección estaba demostrada de antemano.

Lo que se hereda y lo que se paga

Resumir la herencia en una tabla mental ayuda a leer el resto del nivel con las expectativas calibradas. Del lado del activo: fusión garantizada sin servidor, historia completa y direccionable, formato binario estable con compatibilidad hacia atrás entre versiones mayores, y un modelo de datos con semántica precisa en lugar de convenciones. Del lado del pasivo: metadatos que crecen con cada operación, un modelo de documento que no sabe de consultas ni de índices, y una unidad de sincronización —el documento— que hay que dimensionar bien desde el principio porque después es caro cambiarla.

Hay una asimetría importante entre esas dos listas y conviene enunciarla antes de seguir. Los activos son propiedades cerradas: no van a mejorar mucho más porque ya son lo que son. Los pasivos son problemas abiertos sobre los que el proyecto trabaja de forma visible, y la versión 3 es precisamente el episodio en el que uno de ellos —el consumo de memoria— pasa de ser una objeción decisiva a ser un detalle. Evaluar la biblioteca por el estado de sus pasivos en 2023 es un error frecuente y costoso.

Esa distinción también explica por qué la comparación con otras bibliotecas de la familia suele estar mal planteada. Muchas de las alternativas que aparecen en las tablas comparativas consumen menos, y consumen menos precisamente porque descartan la historia una vez fusionada. No están ganando la misma carrera con mejor técnica: están corriendo una carrera más corta. La comparación honesta exige fijar primero qué se quiere conservar, y solo después mirar cuánto cuesta conservarlo, que es el orden en el que la última lección del nivel plantea la decisión.

Queda una advertencia de método para cerrar. La adopción de Automerge ronda las ochenta y cinco mil descargas semanales, una cifra que en el ecosistema JavaScript es modesta en términos absolutos y muy significativa en términos de categoría: no es una dependencia que arrastran los andamiajes por defecto, sino una elegida deliberadamente por equipos que sabían lo que buscaban. Interpretar esa cifra como señal de madurez o de inmadurez, sin mirar quién la usa y para qué, no informa de nada.

Con eso queda montado el andamiaje del nivel. La lección siguiente baja al modelo de programación y explica qué significa exactamente que el documento sea un valor inmutable. La tercera abre la historia y muestra qué se puede preguntar sobre ella. La cuarta cuenta cómo la versión 3 desactivó el pasivo más grave sin tocar nada de lo demostrado. Y la quinta cierra con la única pregunta que de verdad decide una arquitectura: si el dato del que hablas tiene o no tiene una autoridad legítima detrás.