Consistencia Eventual

Resumen

En un sistema con consistencia eventual, una escritura no es visible instantáneamente en todos los nodos. Si escribís un valor en el nodo A y un milisegundo después leés del nodo B, podés ver el valor anterior. Pero si dejás de escribir, eventualmente todos los nodos tendrán el mismo valor. En el interín, distintas lecturas pueden devolver datos distintos.

Es la elección natural de sistemas AP —disponibilidad sobre consistencia—. DNS es el ejemplo clásico: cuando cambiás la IP de un dominio, algunos servidores DNS devuelven la IP vieja durante minutos u horas. Eventualmente, todos devuelven la nueva. El sistema prioriza responder rápido sobre responder con el dato más reciente.

La consistencia eventual no es un bug: es un trade-off deliberado que permite alta disponibilidad, baja latencia y escalabilidad horizontal. Lo importante es que la aplicación esté diseñada para tolerar lecturas desactualizadas.

Alcance y supuestos

Este paquete cubre el concepto a nivel arquitectónico: qué es, qué problema resuelve, cómo se relaciona con otros patrones del ecosistema, y en qué contexto tiene sentido aplicarlo. No cubre detalles de implementación específicos de cada tecnología ni configuraciones de proveedores cloud concretos. Asume que el lector entiende los fundamentos de sistemas distribuidos y arquitectura de software.

Modelo mental

Publicar un libro y distribuirlo en librerías de todo el mundo. La editorial imprime el libro y lo manda a todas las sucursales. La sucursal de Buenos Aires lo recibe el lunes; la de Madrid, el martes. Un lector en Madrid que va el lunes no encuentra el libro. Pero el viernes siguiente, ambas sucursales lo tienen. No hay un momento atómico donde «el libro está disponible en todo el mundo»: la disponibilidad se propaga eventualmente.

Uso práctico

• ✅ Sistemas que priorizan disponibilidad: catálogos, timelines de redes sociales, DNS, CDNs.
• ❌ Operaciones que requieren atomicidad: transferencias bancarias, control de inventario crítico, reservas de último cupo.

La consistencia eventual no es sola: viene acompañada de mecanismos como conflict resolution —CRDTs, last-write-wins, merges manuales— para resolver qué pasa si dos nodos reciben escrituras conflictivas mientras están desconectados.

Ejemplo trabajado: timeline de red social con consistencia eventual

Un usuario publica un post. El servicio de timeline escribe el post en la base de datos y lo propaga asíncronamente a los timelines de sus seguidores. Un seguidor en otra región puede no ver el post durante 2-3 segundos. A cambio, la publicación es instantánea para el autor —el sistema prioriza disponibilidad— y el timeline escala horizontalmente sin bloqueos. Después de 5 segundos sin nuevas escrituras, todos los seguidores ven el post. La experiencia de usuario acepta esa ventana de inconsistencia.

Evidencia

• Wikipedia, Eventual consistency define el modelo, lo contrasta con consistencia fuerte y explica los mecanismos de propagación y resolución de conflictos.