Cómo diseñar una prueba de orden de eventos antes de automatizar un proceso asíncrono

Los procesos asíncronos pueden recibir eventos correctos en un orden incorrecto. Un pago se confirma antes de que llegue el webhook de creación, un correo de cancelación aparece después de una reactivación o una actualización de estado tarda más que la siguiente. Cada evento es válido, pero la secuencia de llegada no representa necesariamente la secuencia real del negocio. Si una automatización asume que “lo último recibido” siempre es “lo último ocurrido”, puede retroceder estados, duplicar acciones o enviar mensajes equivocados. Una prueba de orden de eventos busca comprobar cómo responde el sistema cuando tiempo de ocurrencia y tiempo de llegada dejan de coincidir.

El primer paso es identificar qué eventos cambian estado y cuáles solo informan. No todos requieren la misma protección. Una notificación puede llegar tarde sin consecuencia; una confirmación de pago, cancelación o cambio de permiso puede alterar decisiones. Conviene listar evento, entidad afectada, identificador, timestamp de origen, fuente y acción que habilita. Después se define qué evento tiene autoridad cuando dos mensajes parecen contradecirse. Esa tabla convierte una secuencia implícita en reglas visibles y ayuda a saber qué combinaciones deben probarse antes de conectar el flujo con clientes, dinero o datos sensibles.

La prueba debe separar tiempo de ocurrencia, tiempo de emisión y tiempo de procesamiento. Un evento puede ocurrir a las 10:00, emitirse a las 10:01 y procesarse a las 10:05; otro puede ocurrir a las 10:02 y procesarse a las 10:03. Si el sistema ordena solo por recepción, reconstruirá mal la historia. La automatización necesita decidir qué reloj confía, qué hace cuando falta un timestamp y cómo resuelve fuentes con zonas horarias o precisión diferente. Probar estas variaciones evita que una lógica aparentemente simple dependa accidentalmente de la velocidad de red.

También hay que introducir duplicados deliberados porque muchos proveedores reintentan eventos. Un webhook puede enviarse dos o cinco veces hasta recibir confirmación. Si cada copia dispara la misma acción, una sola compra puede crear varias facturas, correos o registros. La prueba debe reenviar el mismo identificador y comprobar que el resultado externo ocurre una sola vez. Cuando no existe un ID único, el equipo necesita construir una clave de idempotencia con los campos disponibles. El objetivo no es impedir reintentos; es permitirlos sin que la repetición del mensaje se convierta en repetición del efecto.

Los escenarios útiles incluyen retrasos, pérdidas y contradicciones controladas. Se puede procesar primero “pedido enviado” y después “pedido creado”, recibir “cancelado” después de “reactivado”, omitir temporalmente un evento intermedio o retrasar uno durante varios minutos. Cada caso debe tener un estado final esperado y una regla para los eventos tardíos: ignorar, registrar, reconciliar o abrir revisión. La prueba no necesita simular toda la infraestructura; puede usar una cola controlada o un conjunto de mensajes reproducibles. Lo importante es demostrar que la secuencia anómala no cambia el resultado a uno imposible.

La reconciliación es la defensa cuando la historia local deja de ser confiable. Algunos procesos pueden consultar periódicamente la fuente autoritativa y comparar su estado con el registro interno. Si existe diferencia, el sistema corrige o escala. Esa estrategia es útil cuando los eventos son notificaciones y no la única fuente de verdad. La prueba debe comprobar también ese mecanismo: qué dato gana, qué cambios son reversibles y qué acciones ya ejecutadas no pueden deshacerse automáticamente. Un correo enviado no vuelve, aunque el estado pueda corregirse; por eso la reconciliación debe convivir con límites sobre efectos irreversibles.

Una automatización madura demuestra consistencia incluso cuando la red se comporta mal. Antes de producción, el equipo conserva una batería pequeña de secuencias: normal, fuera de orden, duplicada, retrasada y con evento faltante. Cada versión importante del flujo vuelve a ejecutarlas. Si todas terminan en el estado correcto y sin duplicar efectos, existe evidencia de resiliencia. La meta no es imponer orden a internet, sino diseñar un proceso que no dependa de recibir mensajes en una secuencia perfecta. Cuando el sistema conoce identidad, autoridad temporal e idempotencia, los eventos tardíos dejan de ser sorpresas y se vuelven condiciones previstas.