Todo el mundo quiere actualizaciones en tiempo real hasta que se da cuenta de que "rápido" y "correcto" no son lo mismo. En un sistema distribuido, los eventos pueden viajar a la velocidad de la luz y aun así llegar en el orden incorrecto. Los WebSockets se desconectan y vuelven a conectarse. Los message brokers vuelven a entregar paquetes. Los background workers compiten contra cancelaciones por tiempo de espera (timeout). ¿El resultado? Un cliente podría ver el evento 42, luego el evento 40, y luego una instantánea que afirma que el sistema ya está en el evento 45. Si estás construyendo flujos de trabajo de agentes de larga duración, ese caos no es un caso excepcional. Es la norma. Corrige el orden de tus eventos antes de preocuparte por recortar milisegundos en la entrega.
La desordenada realidad del "tiempo real"
El tiempo real es una propiedad de transporte. Describe con qué rapidez se mueve un paquete a través de un cable, no si la historia que cuenta tiene sentido. Las tareas de larga duración amplifican cada inconsistencia porque se extienden a través del tiempo. Un trabajo de entrenamiento de un modelo, un flujo de aprobación de múltiples pasos o un pipeline de renderizado de video pueden emitir docenas de eventos a lo largo de minutos u horas. Durante ese intervalo, cualquier cosa puede salir mal.
Un broker podría reintentar un mensaje porque se perdió un acknowledgement. Un balanceador de carga podría enrutar dos eventos por diferentes rutas de red, permitiendo que el más nuevo llegue primero. Un proceso worker podría morir después de escribir en una base de datos pero antes de publicar el evento de éxito, solo para que un segundo worker tome la tarea y emita su propio progreso. Si tu frontend asume que el último mensaje es el mensaje más veraz, pintará un estado que nunca existió. Los usuarios verán una insignia de "completado" parpadear de nuevo a "procesando" o, peor aún, una tarea cancelada que de repente se resucita. La velocidad sin orden es solo confusión a una mayor tasa de fotogramas.
Los números de secuencia son el verdadero reloj
La solución son números de secuencia estrictos y monotónicos generados por el productor. Cada operación que cambia el estado recibe un número que aumenta exactamente en uno, sin huecos y sin reversiones (rollbacks). Ese número debe persistirse en la misma transacción que el evento mismo. Si la fila de la base de datos se actualiza pero el commit de la secuencia falla, se revierten ambos. Esto mantiene la línea de tiempo lógica atómica con el cambio de estado.
Los IDs de evento siguen siendo útiles, pero resuelven un problema diferente. Un ID de evento identifica un payload específico para que puedas deduplicarlo cuando el broker entrega el mismo mensaje dos veces. Un número de secuencia, por otro lado, te indica dónde pertenece ese payload en la cadena causal. Expone huecos. Expone el orden. Un timestamp no hace ninguna de las dos cosas. Los relojes se desvían, el NTP retrocede y las máquinas virtuales se pausan. Usa los timestamps solo para fines de visualización, algo como "Comenzó hace 3 minutos", y nunca como una clave de ordenación para la lógica de negocio.
Cómo debe manejar el cliente el flujo
Una vez que el productor garantiza una secuencia monotónica, el consumidor recibe reglas simples y estrictas. Si un número de secuencia entrante es menor o igual al último número aplicado, descártalo. Es un duplicado o un rezagado desactualizado. Si la secuencia es exactamente uno mayor que el último número aplicado, aplícalo inmediatamente. Ese es el happy path. Si la secuencia salta hacia adelante, por ejemplo, esperabas el 12 pero recibiste el 15, algo falta. Almacena el nuevo evento en un buffer y solicita al servidor un replay comenzando desde la siguiente secuencia esperada. No adivines. No te saltes pasos con la esperanza de que el hueco no importe.
Los estados terminales deben tratarse como irrevocables. Una vez que una tarea se marca como completada, fallida o cancelada, el cliente debe rechazar cualquier cambio de estado posterior para esa operación. Esto suena obvio hasta que te enfrentas a