La arquitectura local-first a fondo: almacenamiento en el navegador y SQLite sobre OPFS, Web Workers, la teoría de los CRDT y sus algoritmos de secuencia, almacenamiento direccionado por contenido, motores de sincronización, identidad sin servidor y cifrado extremo a extremo.
Cada nivel construye sobre el anterior. Sin saltos, sin huecos.
La visión aérea: los siete ideales, el almacenamiento del cliente, los CRDT, el almacenamiento por contenido, los motores de sincronización y la identidad sin servidor.
El artículo de Ink & Switch que fundó el término: rapidez, multidispositivo, offline, colaboración, longevidad, privacidad y control del usuario. Qué promete cada ideal y cuál se incumple más.
Offline-first, local-first, sync-first y app nativa no son sinónimos. Qué significa cada término, quién lo usa para vender y en qué se distinguen técnicamente.
Por qué la arquitectura cliente-servidor produce ruedas de carga: el viaje de ida y vuelta, el servidor como punto único de fallo, y el coste que nadie mide de la latencia acumulada.
Longevidad, privacidad y control: qué pasa con tus datos cuando la empresa cierra, cambia de precio o de términos. El argumento que decide la arquitectura y no es de ingeniería.
Los casos donde local-first es la respuesta equivocada: autoridad central obligatoria, datos que no caben, permisos que cambian, cumplimiento normativo y equipos pequeños.
Todo lo que el navegador ofrece para guardar: cookies, localStorage, sessionStorage y sus límites reales. Por qué los cinco megabytes de localStorage no son negociables.
Almacenes de objetos, índices, transacciones y cursores. El modelo mental de la única base de datos que todos los navegadores traen de serie.
Dónde se va el tiempo: la serialización estructurada, el coste por transacción, los patrones que lo hacen soportable y los envoltorios que valen la pena.
El Origin Private File System: un sistema de archivos real, privado por origen, sin diálogos de permiso. Qué es, qué lo diferencia de la File System Access API y qué te da.
El acceso síncrono solo existe dentro de un Worker, y esa única restricción condiciona la arquitectura entera de tu aplicación. Por qué es así y cómo se convive con ello.
El modelo de cuota por origen, el modo best-effort, el desalojo silencioso bajo presión de disco, y cómo pedir persistencia de verdad con la API de almacenamiento.
La compilación oficial a WebAssembly, la arquitectura de VFS que hace posible enchufarle cualquier backend de almacenamiento, y qué significa tener SQL de verdad en el cliente.
El VFS de OPFS, las alternativas de la comunidad, el rendimiento medido en bases de varios gigabytes y los modos de concurrencia que tienes que elegir.
RxDB, PouchDB, Dexie, TinyBase, DuckDB en WebAssembly y los almacenes de los propios motores de sync. Qué resuelve cada uno y con qué criterio se elige.
El problema de mantener la interfaz sincronizada con la base local: consultas vivas, invalidación, y por qué esto define la ergonomía de toda la aplicación.
Hilos reales sin memoria compartida: el paso de mensajes, el algoritmo de clonado estructurado, qué se puede transferir y qué se copia.
El problema de las pestañas múltiples sobre la misma base de datos. SharedWorker, su soporte irregular, y las alternativas cuando no está disponible.
La API de bloqueos del navegador, la elección de líder entre pestañas, y el patrón que evita que dos pestañas corrompan la misma base.
Juntar las piezas: la base en un Worker dedicado, RPC tipado sobre postMessage, propagación de cambios a todas las pestañas y arranque en frío.
El teorema CAP aplicado a tu aplicación, qué es de verdad una partición de red, y por qué el orden de los eventos es el problema central y no un detalle.
Por qué la hora del sistema es inservible para ordenar eventos distribuidos: deriva, ajustes, saltos. La relación de precedencia causal y los relojes de Lamport.
Vector clocks y version vectors para detectar concurrencia real, su coste en espacio, y los relojes lógicos híbridos que juntan lo mejor de ambos mundos.
Qué es exactamente un conflicto, por qué "gana la última escritura" es la respuesta más común y la peor, y qué datos desaparecen sin que nadie se entere.
La transformación operacional que hizo posible Google Docs y los tipos replicados sin conflicto. De dónde viene cada una, qué exige y dónde vive hoy cada enfoque.
La estructura algebraica que hay debajo: semirretículo de unión, conmutatividad, asociatividad e idempotencia. Por qué esas tres propiedades bastan para garantizar convergencia.
Las dos familias, basada en estado y basada en operaciones, qué exige la red a cada una, y los CRDT delta que resolvieron el problema de enviar el estado entero.
G-Counter y PN-Counter: el punto de partida para entender la mecánica. Por qué un contador distribuido no es un número y qué implica eso.
G-Set, 2P-Set y OR-Set. El problema del borrado en un sistema sin autoridad central, las lápidas que deja detrás y por qué añadir es fácil y quitar no.
LWW-Register y MV-Register: guardar un valor cuando dos personas lo escriben a la vez. Resolver por reloj o exponer el conflicto al usuario.
Componer CRDT dentro de CRDT para representar documentos anidados, el problema de la eliminación de claves y el modelo JSON que usan las librerías reales.
Por qué una lista es el caso difícil: hace falta poder crear un identificador estrictamente entre otros dos, infinitas veces, sin coordinación.
Los algoritmos clásicos de lista replicada, sus estructuras internas y el compromiso que hace cada uno entre tamaño del identificador y coste de inserción.
El artículo de 2019 que destapó que casi todos los algoritmos entrelazan el texto de dos personas que escriben a la vez en el mismo punto. Por qué pasó desapercibido décadas.
El algoritmo que definió y resolvió la propiedad de no intercalación maximal, cómo lo consigue y por qué su formulación resultó ser más fácil de optimizar que las anteriores.
El enfoque que registra las operaciones originales en vez de la metadata del CRDT: un orden de magnitud menos de memoria y cargas de documento drásticamente más rápidas.
Mover un nodo dentro de un árbol replicado puede crear un ciclo cuando dos personas lo hacen a la vez. Las estrategias para impedirlo y el coste de cada una.
Implementar un conjunto replicado paso a paso, con su prueba de convergencia y sus lápidas, para tocar con las manos lo que las lecciones anteriores describen.
Implementar una lista replicada completa: identificadores, inserción, borrado, recorrido y la función de mezcla. El ejercicio que fija todo lo demás.
Cómo se demuestra que tu implementación converge: pruebas basadas en propiedades, generación de historias concurrentes, simulación de particiones y reducción de casos.
El modelo de documento, los tipos compartidos, el sistema de awareness para los cursores ajenos y los proveedores de transporte. Por qué domina el mercado de editores.
El modelo de documento con historia completa, el formato de almacenamiento columnar de la versión 3 y las capacidades de viaje en el tiempo que eso habilita.
La apuesta escrita en Rust: texto enriquecido, árboles con movimiento y el algoritmo de recorrido del grafo de eventos. Qué gana y qué le falta de ecosistema.
Tamaño en disco, memoria en caliente, velocidad de carga, madurez del ecosistema y forma de los datos. Un criterio de elección, y los casos donde ninguno es la respuesta.
Un CRDT que guarda todo crece para siempre. Lápidas, compactación, instantáneas y la pregunta incómoda de qué historia puedes tirar sin romper a quien lleva meses desconectado.
La idea que cambia el modelo: el nombre de un dato es su hash. Inmutabilidad, deduplicación gratuita y verificación de integridad sin confiar en quien te lo envía.
Grafos acíclicos dirigidos de Merkle, el troceado de ficheros grandes, los identificadores de contenido y el modelo de datos enlazados que usan los sistemas distribuidos.
Git es un almacén direccionado por contenido con una interfaz de control de versiones encima. Objetos, árboles, commits y packfiles: lo que se aprende leyéndolo así.
Qué se le pide a un hash en este contexto, por qué la velocidad y el paralelismo importan tanto como la resistencia a colisiones, y los árboles de hash verificables por trozos.
El problema de averiguar la diferencia entre dos réplicas sin transmitirlas enteras: version vectors, filtros de Bloom y reconciliación de conjuntos.
La pila que el navegador te da para conectar dos clientes: ICE, STUN, TURN, DTLS y SCTP. Por qué se diseñó para vídeo y qué cuesta usarla para sincronizar datos.
Las alternativas modernas: la pila modular de libp2p, el enfoque de iroh sobre QUIC con claves como direcciones, y las tasas reales de éxito al perforar NAT.
El panorama de 2026 ordenado: autoridad en el servidor frente a convergencia por CRDT, sincronización de tablas frente a sincronización de documentos, y qué implica cada eje.
Zero, ElectricSQL, PowerSync, Jazz, LiveStore y compañía: cómo funciona cada uno por dentro, qué base de datos exige y para qué tipo de aplicación está pensado.
Quién eres cuando no hay servidor de sesiones: identificadores descentralizados, cadenas de certificados con enlace tardío y autorización delegada que funciona sin conexión.
El choque entre cifrar y sincronizar: qué puede ver el servidor, la gestión de claves entre dispositivos, los protocolos de mensajería en grupo y el control de acceso local-first.
El problema más difícil y el peor documentado: cambiar la forma de los datos cuando viven en dispositivos ajenos que llevan meses sin abrirse. Compatibilidad en las dos direcciones.
Cómo resolvieron esto en productos reales de escritorio y web: qué sincronizan, qué no, dónde ponen la autoridad y qué compromisos aceptaron a cambio.
El modelo mental completo, el árbol de decisiones para elegir arquitectura, lo que sigue sin estar resuelto y hacia dónde va el campo.
Empieza por los fundamentos y sube nivel a nivel hasta el dominio total.
Comenzar el camino →