Explicando la consistencia eventual a un desarrollador de bases de datos relacionales

En un sistema distribuido, los mismos datos lógicos pueden existir en varias máquinas, o un servicio puede mantener una vista local de datos propiedad de otro servicio. La consistencia eventual significa que una actualización no tiene que llegar a todas las copias antes de que el sistema la acepte. Durante un tiempo, diferentes lectores pueden ver diferentes valores. Si las actualizaciones se detienen y la comunicación y la replicación continúan con éxito, las copias convergerán en el mismo valor. "Eventual" por sí solo no promete un plazo específico.

Imagina varias sucursales de una biblioteca guardando copias de su catálogo. Con consistencia fuerte, una vez que un bibliotecario cambia la ubicación de un libro y recibe confirmación, cualquier búsqueda de catálogo posterior debe reflejar ese cambio o uno más reciente. Las sucursales se coordinan para no responder con una ubicación desactualizada; si no pueden establecer el valor actual, pueden tener que esperar o devolver un error.

Con consistencia eventual, una sucursal puede registrar el cambio y notificar a las otras después. Alguien en otra sucursal podría ver brevemente la ubicación antigua del estante. Esa sucursal no está necesariamente funcionando mal: está respondiendo desde una copia local que aún no se ha puesto al día. Este es el cambio clave de tu flujo de trabajo SQL familiar: una escritura exitosa no significa necesariamente que todos los lugares desde los que puedes leer ya la reflejen.

Hay una distinción terminológica importante. La C en ACID significa que las transacciones preservan los invariantes de la base de datos, como las restricciones; la consistencia fuerte entre réplicas generalmente se refiere a la linealizabilidad, donde las operaciones se comportan como si hubiera una copia actualizada. Estas no son la misma garantía. Una base de datos puede ejecutar transacciones ACID localmente mientras replica asincrónicamente sus resultados en otros lugares. Además, lo que ve una consulta relacional depende de su nivel de aislamiento de transacciones y su instantánea.

¿Por qué aceptar lecturas obsoletas? La coordinación cuesta tiempo y hace que las operaciones dependan de la comunicación entre máquinas. A través de regiones, los viajes de ida y vuelta de red pueden ser sustanciales. La replicación asincrónica permite lecturas locales y, en algunos diseños, escrituras locales sin esperar a las réplicas distantes, mejorando la latencia y reduciendo la dependencia de otros nodos.

El teorema CAP agudiza esta compensación durante una partición de red: cuando los grupos de nodos no pueden comunicarse, un sistema distribuido no puede garantizar la consistencia linealizable y la disponibilidad para cada solicitud a un nodo que funciona. Para preservar la consistencia, a veces debe retrasar o rechazar operaciones. Para seguir sirviendo solicitudes en ambos lados, a veces debe permitir respuestas o actualizaciones que aún no se pueden conciliar con el otro lado. La consistencia eventual es un enfoque común para los sistemas que eligen la disponibilidad en esa situación. CAP no significa "elige siempre dos"; la elección inevitable surge durante las particiones. Las actualizaciones concurrentes también necesitan una regla explícita de resolución de conflictos: la convergencia no es magia.

El recuento de "me gusta" de una aplicación social es un buen candidato. Ver brevemente 120 "me gusta" en lugar de 121 suele ser inofensivo. Por el contrario, la consistencia eventual por sí sola es inaceptable para hacer cumplir la regla de no sobregiro de una cuenta bancaria: dos servicios que leen el mismo saldo obsoleto podrían autorizar retiros. Esa decisión necesita una verificación y actualización atómica autorizada o una coordinación equivalente. Incluso dentro de esa aplicación bancaria, un panel de análisis podría quedarse atrás de forma segura.

Dos patrones ayudan a los usuarios a manejar el retraso. Primero, use una interfaz de usuario optimista con comportamiento de lectura-tu-escritura: muestre inmediatamente el nuevo comentario de un usuario y manténgalo visible mientras las réplicas se ponen al día, o dirija las lecturas de ese usuario a una fuente que haya aplicado su escritura. Marque los cambios no confirmados como pendientes y maneje claramente los fallos en lugar de tratarlos silenciosamente como guardados.

Segundo, haga explícito el procesamiento asincrónico. Muestre "Su cambio se ha guardado; los resultados de la búsqueda se están actualizando", luego sondee o use notificaciones push hasta que la vista de lectura relevante refleje la actualización. Distinguir los estados aceptado, en procesamiento y completo convierte una pantalla aparentemente incorrecta en un flujo de trabajo comprensible.

De "La base de datos siempre tiene razón" a "La base de datos tendrá razón en breve"

Cuando escribes SQL contra una única base de datos relacional, vives dentro de una garantía muy cómoda. Haces BEGIN, haces UPDATE, haces COMMIT, y a partir de ese instante, cada conexión en el mundo ve el nuevo valor. No hay una ventana en la que un usuario vea la fila antigua y otro vea la nueva. Esa garantía es la "C" e "I" de ACID — consistencia y aislamiento — impuesta por bloqueos, cerrojos y un único registro de escritura anticipada en una máquina.

Los sistemas distribuidos rompen esa comodidad, no por descuido, sino porque la física de las redes obliga a una elección. Comprender esa elección es la totalidad de la consistencia eventual.

1. Consistencia Fuerte vs. Eventual: La Analogía

La consistencia fuerte es una única pizarra en una única sala.

Imagina que tu equipo mantiene su horario de guardia en una pizarra física en una oficina. Si quieres cambiar quién está de guardia, entras en la sala y, mientras borras y reescribes, nadie más puede leerla — esperan en la puerta. En el momento en que te alejas, todos los que entran ven exactamente el mismo horario correcto. Hay exactamente una copia de la verdad, y el acceso a ella está serializado. Esa es tu instancia de Postgres con un bloqueo de fila.

La consistencia eventual es un rumor que se propaga por una empresa.

Ahora imagina que tu empresa tiene oficinas en Berlín, São Paulo y Singapur, y cada oficina mantiene su propia copia del horario en su propia pizarra. Cambias el tablero de Berlín. Se envía un mensajero a São Paulo y Singapur. Durante los siguientes segundos — o minutos, si el mensajero se topa con tráfico — un colega en Singapur que lee su tablero local obtiene el horario antiguo. No están leyendo datos corruptos; están leyendo datos que son correctos hasta hace un momento. Dada la ausencia de cambios adicionales, los tres tableros convergerán en el mismo valor. Esa garantía de convergencia — "si las escrituras se detienen, todas las réplicas estarán de acuerdo" — es precisamente lo que significa "eventual".

El cambio mental clave: obsoleto no es lo mismo que incorrecto. Los datos obsoletos son un estado pasado válido del sistema. Los datos corruptos son un estado que el sistema nunca tuvo. La consistencia eventual permite lo primero y aún así prohíbe lo segundo.

2. Por Qué los Sistemas Distribuidos Eligen Esto: El Compromiso CAP

El teorema CAP (teorema de Brewer) dice que un almacén de datos distribuido puede ofrecer como máximo dos de tres propiedades simultáneamente:

• C — Consistencia: cada lectura devuelve la escritura más reciente.
• A — Disponibilidad: cada solicitud recibe una respuesta sin error.
• P — Tolerancia a particiones: el sistema sigue funcionando cuando la red falla o retrasa mensajes entre nodos.

Aquí está la parte que confunde a la gente: P no es opcional. En el momento en que tus datos residen en más de una máquina, ocurrirán particiones de red — falla un conmutador, se corta un cable, una zona de disponibilidad en la nube se vuelve inalcanzable, una pausa de GC hace que un nodo parezca muerto. No puedes "elegir" no tener particiones, al igual que no puedes elegir no tener gravedad. Por lo tanto, CAP es realmente una pregunta forzada: cuando ocurre una partición, ¿sacrificas C o A?

• Elegir CP (sacrificar disponibilidad): Durante una partición, los nodos que no pueden confirmar que tienen los datos más recientes se niegan a responder. Las lecturas y escrituras devuelven errores o se bloquean hasta que la partición se recupera. Tus datos nunca están obsoletos, pero tu servicio se cae para algunos usuarios. Esto es aproximadamente lo que hace un sistema distribuido que utiliza consenso (Raft/Paxos — piensa en etcd, ZooKeeper o un clúster SQL replicado sincrónicamente).

• Elegir AP (sacrificar consistencia fuerte): Durante una partición, cada nodo sigue respondiendo con los mejores datos que tiene localmente y se reconcilia más tarde cuando la conectividad regresa. Nadie ve un error; algunas personas ven valores obsoletos durante un tiempo. Esto es DynamoDB en su modo predeterminado, Cassandra con configuraciones de quorum bajas, DNS y la mayoría de las rutas de lectura respaldadas por CDN.

Hay dos presiones adicionales más allá de las particiones:

Latencia. La consistencia fuerte a través de la geografía requiere coordinación, y la coordinación cuesta un viaje de ida y vuelta por la red. Si una escritura en Frankfurt debe ser confirmada por una réplica en Sídney antes de que devuelvas 200 OK, has añadido ~250 ms de impuesto a la velocidad de la luz a cada solicitud. Eso no es un error que puedas optimizar; es el diámetro del planeta. La extensión PACELC de CAP captura esto: si está Particionado, elige Disponibilidad o Consistencia; de lo contrario, elige Latencia o Consistencia. Incluso en una red perfectamente saludable, sigues pagando por la coordinación.

Acoplamiento en microservicios. En tu monolito, la tabla de pedidos y la tabla de inventario estaban en la misma base de datos, por lo que BEGIN TRANSACTION cubría ambas. Una vez que Pedidos e Inventario son servicios separados con almacenes separados, una única transacción ACID entre ellos requiere un commit en dos fases — que mantiene bloqueos a través de una red, y donde un fallo del coordinador puede dejar a los participantes bloqueados indefinidamente. La mayoría de los equipos rechazan el 2PC y en su lugar utilizan patrones asíncronos (publicación de eventos, el patrón outbox, sagas), y esos patrones son eventualmente consistentes por construcción. La consistencia eventual a menudo no es una elección de base de datos en absoluto; es la consecuencia inevitable de descomponer tu sistema en servicios desplegables de forma independiente.

Por lo tanto, el resumen honesto es: los sistemas distribuidos eligen la consistencia eventual porque proporciona disponibilidad durante fallos, baja latencia a escala e independencia entre servicios — y porque para una gran clase de datos, unos pocos cientos de milisegundos de obsolescencia no tienen coste comercial.

3. Dónde Está Bien, y Dónde Absolutamente No Lo Está

Aceptable: un contador de "me gusta" o visualizaciones en una publicación social, o un índice de búsqueda.

Digamos que una publicación tiene 4.812 "me gusta". Te gusta; la escritura va a una réplica local y se devuelve instantáneamente. Otro usuario en una región diferente se actualiza y ve 4.812 durante otros 800 ms antes de ver 4.813. ¿Cuál es el daño? Nada. No se movió dinero, no se rompió ninguna promesa, no se tomó ninguna decisión basándose en el número obsoleto. Lo mismo ocurre con los índices de búsqueda (un artículo recién publicado que tarda dos segundos en ser buscable), los avatares de perfiles de usuario, los feeds de recomendaciones y los paneles de análisis. A cambio de ese retraso inofensivo, la función permanece activa durante una partición de red y responde en milisegundos de un solo dígito en todo el mundo.

La prueba útil: pregunta qué se rompe si un usuario actúa sobre datos que tienen 5 segundos de antigüedad. Para un contador de "me gusta", nada se rompe.

Inaceptable: el lado del débito de una transferencia financiera, o el inventario de un artículo escaso.

Considere mover 500 € entre dos cuentas, o una verificación de saldo de cuenta antes de un retiro. Si la réplica del saldo está obsoleta, dos retiros de cajero automático de 500 € contra un saldo de 600 € pueden ser aprobados, y has creado 400 € de la nada. Reconciliar eso "más tarde" significa que un cliente real debe dinero real, y posiblemente un problema regulatorio. Lo mismo se aplica a la venta de la última unidad de entradas de conciertos, la asignación de nombres de usuario únicos o la aplicación de la regla "un voto por persona". Todas estas son restricciones de unicidad o de invariante no negativo, e invariantes que deben cumplirse en el instante de la decisión no pueden ser impuestas por un sistema que solo promete acuerdo después.

Para estos casos, necesitas consistencia fuerte en la ruta crítica: una transacción de partición única, un almacén respaldado por consenso, escrituras condicionales/comparar y establecer, o un bloqueo o concesión distribuida con un alcance estrecho alrededor del invariante.

El matiz importante: esta no es una decisión a nivel de aplicación. En el mismo sistema de comercio electrónico, la autorización de pago del pago es fuertemente consistente, mientras que el carrusel "los clientes también compraron", el recuento de reseñas de productos y la lista del historial de pedidos son eventualmente consistentes. Los diseños maduros eligen la consistencia por operación, pagando el coste de coordinación solo donde un invariante lo exige genuinamente. Una vía de escape común es diseñar el invariante: en lugar de "reservar el último billete atómicamente", modelar un libro de contabilidad de eventos de reserva de solo anexión y compensar con una saga si se vende en exceso — que es exactamente cómo las aerolíneas siempre han manejado la sobreventa.

4. Dos Patrones para Ocultar el Retraso a los Usuarios

Los usuarios no tienen un modelo mental del retraso de replicación. Si hacen clic en "Guardar", ven un mensaje de éxito, navegan a una lista y su cambio no está allí, concluirán que tu producto está roto y volverán a hacer clic en "Guardar", creando un duplicado. Dos patrones resuelven la mayor parte de esto.

Patrón A: Lectura de las propias escrituras (consistencia de sesión), a través de UI optimista o lecturas fijas.

El fallo más discordante es que un usuario no vea su propio cambio. La solución es garantizar la consistencia solo para la sesión del propio usuario, lo que es mucho más barato que la consistencia fuerte global. Dos implementaciones:

• UI optimista: el cliente renderiza inmediatamente el resultado esperado de la carga útil que acaba de enviar, en lugar de esperar a volver a leer del servidor. Cuando publicas un comentario, el comentario aparece en el hilo instantáneamente, renderizado desde el estado local, mientras la escritura se propaga en segundo plano. Si el servidor finalmente lo rechaza, el cliente revierte el elemento y muestra un error. Esto es lo que hace que las aplicaciones de chat y Google Docs se sientan instantáneas a pesar de ser muy asíncronas.
• Lecturas fijas / ancladas: después de una escritura, dirige las lecturas de ese usuario al primario (o a la réplica que aceptó la escritura) durante una ventana corta, o pasa un token de versión — un token de consistencia "leer-tus-escrituras", LSN o reloj vectorial — con lecturas posteriores para que el sistema pueda esperar hasta que la réplica se ponga al día al menos hasta esa versión. El coste lo paga solo la pequeña fracción de sesiones que acaban de escribir.

Patrón B: Estado explícito "pendiente" en el modelo de dominio y la UI.

En lugar de fingir que una operación es instantánea, haz del paso asíncrono una parte de primera clase de tu modelo de datos y tu interfaz. Una transferencia bancaria muestra como "Pendiente — se completará mañana"; una carga de video muestra "Procesando"; un pedido muestra "Pago confirmado, pendiente de cumplimiento." Esto es honesto, coincide con las expectativas del mundo real de los usuarios (todo el mundo entiende que un cheque tarda tiempo en hacerse efectivo), y convierte una ausencia confusa de datos en información significativa. Técnicamente, esta es la misma idea que una máquina de estados sobre el ciclo de vida de una entidad, impulsada por eventos de dominio, y se empareja naturalmente con una saga: cada etapa transiciona el estado visible, y un fallo lo transiciona a un estado compensatorio como "Reembolsado" en lugar de desaparecer silenciosamente.

Dos prácticas de apoyo que vale la pena internalizar:

• Haz que cada escritura sea idempotente. Adjunta una clave de idempotencia generada por el cliente a cada solicitud. Si un usuario hace doble clic porque la UI se retrasó, o se dispara una reintento después de un tiempo de espera, la segunda solicitud se reconoce y se descarta en lugar de crear un segundo pedido. En un mundo eventualmente consistente, la entrega "exactamente una vez" es una ficción; los manejadores idempotentes son cómo obtienes efectos "exactamente una vez".
• Diseña para la convergencia, no para el último escritor gana por reloj. Los relojes de pared en diferentes máquinas discrepan. Utiliza versionado lógico (relojes vectoriales, marcas de tiempo de Lamport), registros de eventos de solo anexión o CRDTs (contadores, conjuntos, registros con funciones de fusión definidas) para que las actualizaciones concurrentes se fusionen de forma determinista en lugar de que una sobrescriba silenciosamente a la otra.

El Modelo Mental a Mantener

Deja de pensar en la base de datos como una única hoja de papel que contiene la verdad actual, y empieza a pensar en ella como un registro de cosas que sucedieron, más muchos lectores en diferentes puntos de ese registro. ACID te dio la ilusión de que todos están en el mismo punto del registro en todo momento; esa ilusión es asequible en una máquina y costosa en muchas.

Tu trabajo como ingeniero ya no es "hacer que todo sea consistente". Es identificar el pequeño número de invariantes que nunca deben violarse — dinero, unicidad, recuentos no negativos, autorización — pagar por la consistencia fuerte exactamente allí, y dejar que todo lo demás converja a su propio ritmo mientras la UI le cuenta al usuario una historia honesta sobre lo que está sucediendo. Una vez que puedas articular para cualquier característica dada cuánto retraso es demasiado y qué se rompe si lo excedemos, habrás hecho la transición.