En sistemas distribuidos, la consistencia eventual no es un fallo: es una propiedad del diseño. Este ensayo técnico explica por qué tratar la llegada desordenada de eventos como un error y aplicar reintentos o colas de mensajes muertos suele crear más problemas de los que resuelve, y propone una arquitectura alternativa basada en almacenar cada evento y verificar continuamente si ya están disponibles todos los datos necesarios para procesarlo.
El artículo parte de un caso concreto: un servicio que necesita un evento de "usuario creado" y otro de "suscripción creada" antes de procesar un pago. Si el segundo llega antes que el primero, la tentación es reintentar o derivar el mensaje a una dead-letter queue. Pero esa decisión asume que algo ha fallado, cuando en realidad el sistema funciona exactamente como se diseñó: la información acabará llegando.
La alternativa consiste en almacenar cada pieza de información entrante y comprobar, con cada nuevo evento, si ya se cumplen los prerequisitos. Cuando lo hacen, se ejecuta el trabajo; si no, no se hace nada. Sin reintentos, sin colas de mensajes muertos ni intervención manual para reordenar eventos tras caídas del servicio.
El texto distingue entre fallos transitorios —un timeout de red, un paquete perdido— donde un reintento puntual tiene sentido, y problemas estructurales de consistencia, donde multiplicar reintentos solo añade infraestructura y complejidad operativa. La lección general: antes de elegir una solución, hay que identificar correctamente el problema, porque aplicar las herramientas de disponibilidad a la consistencia eventual produce sistemas más difíciles de razonar y mantener.