Consistencia eventual (BD)
La garantía de consistencia común más débil: si no ocurren nuevas escrituras, todas las réplicas acabarán convergiendo al mismo valor. No dice nada sobre cuánto tarda ni qué se ve mientras tanto — solo que al final se igualan.
Idea: priorizar la disponibilidad y la baja latencia sobre la consistencia inmediata. Las réplicas pueden diferir temporalmente (una lectura puede dar datos «viejos» justo después de una escritura), pero los mecanismos de reparación (read repair, anti-entropy) garantizan que converjan. Ejemplos clásicos: DNS (un cambio se propaga durante minutos u horas), Cassandra/Dynamo en sus modos más débiles, S3 (históricamente). Ventaja: alta disponibilidad, tolerancia a particiones, escalabilidad (AP en CAP). Precio: la aplicación debe tolerar ver valores obsoletos y, posiblemente, conflictos. «Eventual» es notoriamente vago → variantes más fuertes como «read-your-writes» y la consistencia causal añaden garantías prácticas encima. Lo opuesto a la consistencia fuerte o linealizable.