Cómo reproducir un workflow desde eventos sin repetir pagos, correos ni otras acciones externas

Reproducir una ejecución histórica es útil hasta que el replay vuelve a cobrar, enviar o modificar algo real. En sistemas orientados a eventos, conservar la secuencia de cambios permite reconstruir cómo un workflow llegó a determinado estado. Esa capacidad es excelente para depuración, auditoría y pruebas de nuevas versiones. El riesgo aparece cuando la misma lógica que reconstruye el pasado también dispara side effects: un email, un pago, una actualización de CRM o una llamada a un proveedor. Un replay seguro necesita separar las transiciones que pueden volver a calcularse de las acciones externas que solo debían ocurrir una vez.

Empieza distinguiendo eventos de hechos externos y comandos de intención. Un evento como pedidoaprobado describe algo que ya ocurrió; un comando como enviarfactura expresa una acción que el sistema quiere ejecutar. Durante un replay histórico, los eventos existentes deben alimentar el estado, pero los comandos derivados no deberían enviarse automáticamente a producción. Esa separación evita confundir “reconstruir por qué decidimos enviar” con “enviar nuevamente”. Si el diseño mezcla ambos conceptos en una sola función, el primer paso es extraer una capa donde la lógica pura pueda ejecutarse sin tener credenciales ni acceso a sistemas externos.

Cada side effect debería tener una identidad estable que permita reconocer si ya ocurrió. Usa un idempotency key o effect ID derivado del run, entidad y acción. En producción, el executor registra el resultado asociado a esa identidad. En replay, la lógica puede consultar ese registro y devolver una representación del efecto histórico en vez de ejecutarlo otra vez. Por ejemplo, payment:order123:v1 puede resolverse con el recibo ya almacenado. El replay obtiene el mismo dato que necesitaba la máquina de estados sin crear otro pago. La identidad convierte un efecto externo en una referencia que puede ser simulada o recuperada.

Construye un modo de replay que sustituya adaptadores externos por dobles controlados. El mismo workflow puede usar una interfaz sendEmail, pero en replay esa interfaz escribe en un log local y devuelve una respuesta simulada. Para consultas externas, decide si necesitas usar la respuesta histórica capturada o hacer una consulta actual. Ambas opciones responden preguntas distintas: reproducir exactamente el pasado requiere datos históricos; probar cómo se comportaría hoy puede usar datos presentes, pero ya no es una reconstrucción fiel. Etiqueta el modo para que nadie interprete una simulación con datos actuales como evidencia exacta de lo ocurrido.

El orden y la versión de la lógica deben quedar explícitos. Si reproduces eventos de hace tres meses con código actual, el resultado puede cambiar porque reglas, schemas o modelos evolucionaron. Conserva versión del workflow y, cuando sea posible, permite ejecutar la lógica original. Para análisis comparativo, puedes correr versión antigua y nueva sobre la misma secuencia y observar divergencias. Lo importante es no confundir esas dos tareas. Un replay forense busca reconstruir; un replay experimental busca comparar. Ambas deben bloquear side effects reales, pero utilizan criterios distintos para interpretar diferencias.

Verifica que el replay sea aislado antes de confiar en él como herramienta de depuración. Ejecuta pruebas con credenciales de producción ausentes, destinos falsos y adaptadores que fallen si intentan abrir una conexión externa no autorizada. Mantén un contador de side effects simulados y exige que las acciones reales ejecutadas durante replay sean cero. También registra el rango de eventos, versión, modo y hash de los datos utilizados. Así, una sesión de análisis puede repetirse y auditarse. El objetivo es que la seguridad dependa de la arquitectura y no de que la persona recuerde activar un checkbox antes de pulsar “replay”.

Un buen sistema puede volver a pensar el pasado sin volver a actuarlo. Event sourcing ofrece una memoria poderosa, pero esa memoria solo es segura cuando la reconstrucción está desacoplada de la ejecución externa. Los eventos reconstruyen estado; las identidades de efectos recuperan lo que ya ocurrió; los adaptadores de replay simulan lo irreversible. Con esa separación, el equipo puede depurar fallos, comparar versiones y entender decisiones con profundidad sin transformar el análisis en otra transacción. La capacidad de reproducir debe aumentar observabilidad, no multiplicar consecuencias.