Este artículo no describe un incidente puntual, sino una clase de problemas recurrentes y fundamentales que surgen de la consistencia eventual en arquitecturas de bases de datos distribuidas con réplicas de lectura. La causa raíz es la inherente latencia de la replicación asíncrona y la falta de garantías de monotonicidad en las lecturas cuando se distribuyen entre múltiples réplicas. Esto lleva a que diferentes réplicas puedan tener estados ligeramente distintos en un momento dado, y las solicitudes de lectura pueden ser enrutadas a cualquiera de ellas, resultando en la "sensación de que el tiempo retrocede" para el cliente.
Las salvaguardas tradicionales, como la lógica de reintentos en el cliente o el enrutamiento manual de ciertas lecturas al primario, fallan al escalar o introducen una complejidad y latencia inaceptables. Por ejemplo, los reintentos con sleep requieren un "número mágico" y pueden llevar a bucles infinitos si la lógica de negocio no es robusta. Además, la falta de "monotonic reads" significa que incluso dos lecturas consecutivas del mismo cliente pueden ir a réplicas diferentes y ver datos inconsistentes, invalidando la suposición de que "tus escrituras" son visibles inmediatamente.
El problema se agrava en patrones de microservicios con flujos de trabajo que implican lecturas seguidas de escrituras (read-modify-write), donde la consistencia eventual puede llevar a datos incompletos o incorrectos. La necesidad de enrutar selectivamente las lecturas al primario para garantizar la consistencia reduce la eficacia de las réplicas de lectura para escalar, negando parcialmente su propósito. Aurora DSQL aborda esto mediante un diseño donde cada réplica de almacenamiento se actualiza desde "journals" con escrituras estrictamente monótonas, y los procesadores de consultas bloquean las lecturas hasta que las réplicas han visto todos los updates hasta un timestamp de inicio de transacción específico, garantizando así la consistencia fuerte.