Compara flujos impulsados por eventos y APIs de petición-respuesta para procesos de larga duración, enfocándote en aprobaciones, temporizadores, reintentos y trazas de auditoría en apps de negocio.
Un proceso es “de larga duración” cuando no puede terminar en un paso rápido. Puede tardar minutos, horas o días porque depende de personas, tiempo o sistemas externos. Todo lo que implique aprobaciones, traspasos y esperas entra en esta categoría.
Ahí es donde el pensamiento simple de API request-response empieza a fallar. Una llamada API está pensada para un intercambio corto: envías una petición, obtienes una respuesta y sigues. Las tareas largas son más como una historia con capítulos. Necesitas pausar, recordar exactamente en qué punto estás y continuar más tarde sin adivinar.
Ves esto en apps de negocio cotidianas: aprobaciones de compras que requieren manager y finanzas, incorporación de empleados que espera comprobaciones de documentos, reembolsos que dependen de un proveedor de pagos, o solicitudes de acceso que deben revisarse y luego aplicarse.
Cuando los equipos tratan un proceso largo como una sola llamada API, aparecen algunos problemas previsibles:
Un escenario concreto: un empleado solicita acceso a software. El manager aprueba rápido, pero IT tarda dos días en provisionarlo. Si la app no puede mantener el estado del proceso, enviar recordatorios y reanudar con seguridad, aparecen seguimientos manuales, usuarios confundidos y trabajo extra.
Por eso la elección entre flujos impulsados por eventos y APIs de petición-respuesta importa tanto para procesos de negocio de larga duración.
La comparación más simple se reduce a una pregunta: ¿el trabajo termina mientras el usuario espera, o continúa después de que se va?
Una API de petición-respuesta es un intercambio único: una llamada y una respuesta. Encaja con trabajo que se completa rápido y de forma predecible, como crear un registro, calcular una cotización o comprobar inventario. El servidor hace el trabajo, devuelve éxito o error y la interacción termina.
Un flujo impulsado por eventos es una serie de reacciones a lo largo del tiempo. Pasa algo (se crea un pedido, un manager aprueba, expira un temporizador) y el flujo avanza al siguiente paso. Este modelo encaja con trabajo que incluye traspasos, esperas, reintentos y recordatorios.
La diferencia práctica es el estado.
Con request-response, el estado suele vivir en la petición actual más la memoria del servidor hasta que se envía la respuesta. Con flujos impulsados por eventos, el estado debe almacenarse (por ejemplo en PostgreSQL) para que el proceso pueda reanudarse más tarde.
El manejo de fallos también cambia. Request-response suele devolver un error y pedir al cliente que lo intente de nuevo. Los flujos registran el fallo y pueden reintentar de forma segura cuando las condiciones mejoran. También pueden registrar cada paso como un evento, lo que facilita reconstruir la historia.
Un ejemplo simple: “Enviar informe de gastos” puede ser síncrono. “Obtener aprobación, esperar 3 días, recordar al manager y luego pagar” no lo es.
Las aprobaciones son donde el trabajo de larga duración se vuelve real. Un paso del sistema termina en milisegundos, pero una persona puede responder en dos minutos o dos días. La decisión clave de diseño es si modelas esa espera como un proceso pausado, o como un nuevo mensaje que llega más tarde.
Con APIs request-response, las aprobaciones suelen convertirse en una solución incómoda:
Todo esto puede funcionar, pero añade infraestructura solo para conectar el “tiempo humano” con el “tiempo API”.
Con eventos, la aprobación se lee como una historia. La app registra algo como “ExpenseSubmitted”, y más tarde recibe “ExpenseApproved” o “ExpenseRejected”. El motor de flujo (o tu propia máquina de estados) mueve el registro solo cuando llega el siguiente evento. Esto coincide con cómo la mayoría de la gente ya piensa los pasos de negocio: enviar, revisar, decidir.
La complejidad aparece rápido con múltiples aprobadores y reglas de escalado. Puedes requerir manager y finanzas, pero permitir que un manager senior sobreescriba. Si no modelas esas reglas claramente, el proceso se vuelve difícil de razonar y aún más difícil de auditar.
Un patrón práctico es mantener un único registro de “solicitud” y almacenar las decisiones por separado. Así puedes soportar muchos aprobadores sin reescribir la lógica central.
Captura algunos datos como registros de primera clase:
Sea cual sea la implementación, siempre guarda quién aprobó qué, cuándo y por qué como datos, no como una simple línea de log.
La espera es donde las tareas largas empiezan a parecer desordenadas. La gente sale a comer, las agendas se llenan y “te contestamos” se convierte en “¿quién se encarga ahora?” Esta es una de las diferencias más claras entre flujos impulsados por eventos y APIs de petición-respuesta.
Con request-response, el tiempo es incómodo. Las llamadas HTTP tienen timeouts, así que no puedes mantener una petición abierta durante dos días. Los equipos suelen acabar con patrones como polling, un job programado que escanea la base de datos o scripts manuales cuando algo está atrasado. Estos pueden funcionar, pero la lógica de espera vive fuera del proceso. Es fácil perder casos límite, por ejemplo qué pasa si el job corre dos veces, o si el registro cambió justo antes de enviar el recordatorio.
Los flujos tratan el tiempo como un paso normal. Puedes decir: espera 24 horas, envía un recordatorio y luego, a las 48 horas, escala a otro aprobador. El sistema mantiene el estado, así los plazos no quedan escondidos en un proyecto separado de “cron + consultas”.
Una regla de aprobación simple puede leerse así:
Después de que se envía un informe de gastos, espera 1 día. Si el estado sigue “Pending”, notifica al manager. Tras 2 días, si sigue pendiente, reasigna al líder del manager y registra la escalada.
El detalle clave es qué haces cuando se dispara el temporizador pero el mundo cambió. Un buen flujo siempre vuelve a verificar el estado antes de actuar:
Los reintentos son lo que haces cuando algo falló por razones fuera de tu control: la pasarela de pagos se quedó sin respuesta, el proveedor de correo devuelve un error temporal o tu app guardó el paso A pero se cayó antes del paso B. El peligro es simple: intentas de nuevo y haces la acción dos veces.
Con request-response, el patrón habitual es que el cliente llama a un endpoint, espera y, si no recibe un éxito claro, lo intenta otra vez. Para que eso sea seguro, el servidor debe tratar llamadas repetidas como la misma intención.
Un arreglo práctico es una clave de idempotencia: el cliente envía un token único como pay:invoice-583:attempt-1. El servidor guarda el resultado para esa clave y devuelve el mismo resultado en repeticiones. Eso evita cargos dobles, tickets duplicados o aprobaciones repetidas.
Los flujos impulsados por eventos tienen otro tipo de riesgo de duplicación. Los eventos suelen entregarse “al menos una vez”, lo que significa que pueden aparecer duplicados incluso cuando todo funciona. Los consumidores necesitan deduplicación: registrar el ID del evento (o una clave de negocio como invoice_id + step) e ignorar repeticiones. Esta es una diferencia central en los patrones de orquestación: request-response se centra en repetición segura de llamadas, mientras que eventos se centra en repetición segura de mensajes.
Algunas reglas de reintento que funcionan bien en ambos modelos:
Los reintentos deben ser explícitos en el proceso, no un comportamiento oculto. Así haces visibles los fallos y se pueden corregir.
Una traza de auditoría es tu archivo del “por qué”. Cuando alguien pregunta “¿por qué se rechazó este gasto?” deberías poder responder sin adivinar, incluso meses después. Esto importa tanto en flujos impulsados por eventos como en APIs request-response, pero el trabajo se ve distinto.
Para cualquier proceso de larga duración, registra los hechos que te permitan reproducir la historia:
Los flujos impulsados por eventos pueden facilitar la auditoría porque cada paso suele producir un evento como “ManagerApproved” o “PaymentFailed”. Si almacenas esos eventos con el payload y el actor, obtienes una línea de tiempo limpia. La clave es mantener eventos descriptivos y guardarlos en un lugar donde puedas consultarlos por caso.
Las APIs request-response aún pueden ser auditables, pero la historia suele quedar dispersa entre servicios. Un endpoint registra “approved”, otro registra “payment requested” y un tercero “retry succeeded”. Si cada uno usa formatos o campos distintos, la auditoría se convierte en trabajo de detective.
Una solución simple es un “case ID” compartido (también llamado correlation ID). Es un identificador que adjuntas a cada petición, evento y registro de base de datos para la instancia del proceso, como “EXP-2026-00173”. Entonces puedes trazar todo el recorrido a través de los pasos.
La mejor elección depende de si necesitas una respuesta inmediata o que el proceso siga avanzando durante horas o días.
Request-response funciona bien cuando el trabajo es corto y las reglas son simples. Un usuario envía un formulario, el servidor lo valida, guarda datos y devuelve éxito o error. También encaja para acciones claras y de un solo paso como crear, actualizar o comprobar permisos.
Empieza a doler cuando una “única petición” se convierte en muchos pasos silenciosamente: esperar una aprobación, llamar a múltiples sistemas externos, manejar timeouts o ramificarse según lo que pase después. O mantienes una conexión abierta (frágil) o empujas esperas y reintentos a jobs en background que son difíciles de razonar.
Los flujos impulsados por eventos brillan cuando el proceso es una historia en el tiempo. Cada paso reacciona a un nuevo evento (aprobado, rechazado, temporizador disparado, pago fallido) y decide qué hacer después. Esto facilita pausar, reanudar, reintentar y mantener un rastro claro del porqué de cada decisión.
Hay compensaciones reales:
Un ejemplo práctico: un informe de gastos que necesita aprobación del manager, luego revisión de finanzas y finalmente pago. Si el pago falla, quieres reintentos sin doble pago. Eso es naturalmente event-driven. Si sólo es “enviar gasto” con comprobaciones rápidas, request-response suele ser suficiente.
Los procesos de larga duración fallan de maneras aburridas: una pestaña del navegador se cierra, un servidor se reinicia, una aprobación tarda tres días o un proveedor de pagos expira. Diseña para esos retrasos desde el inicio, independientemente del modelo que prefieras.
Empieza por definir un pequeño conjunto de estados que puedas almacenar y reanudar. Si no puedes señalar el estado actual en tu base de datos, no tienes realmente un flujo reanudable.
Para sobrevivir reinicios, persiste lo mínimo necesario para continuar con seguridad. Guarda lo suficiente para volver a ejecutar sin adivinar:
Si puedes reconstruir “dónde estamos” y “qué se permite hacer después” desde los datos guardados, los retrasos dejan de dar miedo.
Los procesos de larga duración suelen romperse cuando llegan usuarios reales. Una aprobación tarda dos días, un reintento se dispara en el momento equivocado y terminas con un pago doble o una traza de auditoría incompleta.
Errores comunes:
Un ejemplo simple: un informe de gastos se aprueba en chat, llega un webhook tarde y la API de pagos se reintenta. Sin estado persistido e idempotencia, el reintento puede pagar dos veces y tus registros no explicarán por qué.
La mayoría de las soluciones pasan por ser explícitos:
El trabajo de larga duración no se trata de una llamada perfecta, sino de mantenerse correcto tras retrasos, personas y fallos.
Escribe qué significa “seguro para continuar” para tu proceso. Si la app se reinicia a mitad, debes poder continuar desde el último paso conocido sin adivinar.
Checklist práctico:
Una prueba de cordura: imagina que el proveedor de pagos se queda sin respuesta justo después de que ya cobraste la tarjeta. Tu diseño debería evitar cobrar dos veces y aún así permitir que el proceso termine.
Escenario: un empleado envía un recibo de taxi de $120 para reembolso. Necesita la aprobación del manager en 48 horas. Si se aprueba, el sistema paga al empleado. Si el pago falla, se reintenta de forma segura y queda un registro claro.
Con APIs request-response, la app suele comportarse como una conversación que tiene que seguir comprobando.
El empleado pulsa Enviar. El servidor crea un registro de reembolso con estado “Pending approval” y devuelve un ID. El manager recibe una notificación, pero la app del empleado suele hacer polling para ver si algo cambió, por ejemplo: “GET reimbursement status by ID”.
Para aplicar el plazo de 48 horas, o ejecutas un job programado que escanee solicitudes vencidas, o guardas un timestamp de deadline y lo compruebas durante los polls. Si el job se retrasa, los usuarios ven un estado desactualizado.
Cuando el manager aprueba, el servidor cambia el estado a “Approved” y llama al proveedor de pagos. Si Stripe devuelve un error temporal, el servidor debe decidir si reintenta ahora, más tarde o falla. Sin claves de idempotencia cuidadas, un reintento puede crear un pago doble.
En un modelo impulsado por eventos, cada cambio es un hecho registrado.
El empleado envía, produciendo un evento “ExpenseSubmitted”. Un flujo inicia y espera ya sea “ManagerApproved” o un evento de temporizador “DeadlineReached” a las 48 horas. Si el temporizador vence primero, el flujo registra un “AutoRejected” y la razón.
Al aprobar, el flujo registra “PayoutRequested” e intenta el pago. Si Stripe se queda sin respuesta, registra “PayoutFailed” con un código de error, programa un reintento (por ejemplo, en 15 minutos) y solo registra “PayoutSucceeded” una vez usando una clave de idempotencia.
Lo que ve el usuario se mantiene simple:
La traza de auditoría queda como una línea de tiempo: enviado, aprobado, comprobado el deadline, intento de pago, fallo, reintento, pagado.
Elige un proceso real y constrúyelo de extremo a extremo antes de generalizar. Aprobación de gastos, incorporación y manejo de reembolsos son buenos puntos de partida porque incluyen pasos humanos, esperas y caminos de fallo. Mantén el objetivo pequeño: un flujo principal y las dos excepciones más comunes.
Escribe el proceso como estados y eventos, no como pantallas. Por ejemplo: “Submitted” -> “ManagerApproved” -> “PaymentRequested” -> “Paid”, con ramas como “ApprovalRejected” o “PaymentFailed”. Cuando ves claramente los puntos de espera y efectos secundarios, la elección entre flujos impulsados por eventos y APIs request-response se vuelve práctica.
Decide dónde vive el estado del proceso. Una base de datos puede ser suficiente si el flujo es simple y puedes hacer cumplir las actualizaciones en un solo lugar. Un motor de flujos ayuda cuando necesitas temporizadores, reintentos y ramificaciones, porque rastrea qué debe pasar después.
Añade campos de auditoría desde el día uno. Almacena quién hizo qué, cuándo y por qué (comentario o código de razón). Cuando alguien pregunte “¿por qué se reintentó este pago?” quieres una respuesta clara sin buscar en logs.
Si construyes este tipo de flujo en una plataforma no-code, AppMaster (appmaster.io) es una opción donde puedes modelar datos en PostgreSQL y crear la lógica del proceso visualmente, lo que puede facilitar mantener aprobaciones y trazas de auditoría coherentes en apps web y móviles.
¿Cuándo debo usar request-response en lugar de un flujo impulsado por eventos?Usa request-response cuando el trabajo termina rápido y de forma predecible mientras el usuario espera, como crear un registro o validar un formulario. Usa un flujo impulsado por eventos cuando el proceso abarca minutos o días, incluye aprobaciones humanas o necesita temporizadores, reintentos y reanudación segura tras reinicios.
¿Por qué las tareas largas fallan cuando se construyen como una única llamada API?Las tareas largas no encajan en una sola petición HTTP porque las conexiones expiran, los servidores se reinician y el trabajo suele depender de personas o sistemas externos. Si lo tratas como una única llamada, normalmente pierdes el estado, generas duplicados en reintentos y terminas con scripts dispersos para manejar esperas.
¿Cómo hago que un proceso de larga duración sea reanudable después de un reinicio?Un buen punto de partida es persistir un estado claro del proceso en tu base de datos y avanzar sólo mediante transiciones explícitas. Almacena el ID de la instancia, el estado actual, quién puede actuar a continuación y las marcas de tiempo claves para poder reanudar tras despliegues, caídas o retrasos.
¿Cuál es la forma más limpia de manejar aprobaciones humanas?Modela las aprobaciones como un paso en pausa que se reanuda cuando llega una decisión, en lugar de bloquear o hacer polling constante. Registra cada decisión como datos (quién decidió, cuándo, aprobación/rechazo y la razón) para que el flujo avance de forma predecible y pueda auditarse.
¿Es mala idea hacer polling para saber el estado de una aprobación?El polling puede servir en casos simples, pero añade ruido y retrasos porque el cliente tiene que preguntar “¿ya terminó?” con frecuencia. Una mejor práctica es enviar una notificación cuando cambie el estado y dejar que el cliente actualice bajo demanda, mientras el servidor sigue siendo la fuente de verdad.
¿Cómo debo implementar recordatorios, plazos y escalados?Trata el tiempo como parte del proceso: almacena plazos y tiempos de recordatorio, y vuelve a verificar el estado actual cuando un temporizador se dispare antes de actuar. Así evitas enviar recordatorios después de que algo ya fue aprobado y mantienes las escalaciones coherentes aunque los jobs se ejecuten tarde o varias veces.
¿Cómo prevengo pagos duplicados o correos duplicados cuando ocurren reintentos?Empieza por claves de idempotencia para cualquier efecto externo, como cobrar una tarjeta o enviar un correo, y guarda el resultado para esa clave. Así los reintentos son seguros: repetir la misma intención devuelve el mismo resultado en lugar de repetir la acción.
¿Cómo manejo eventos duplicados en un sistema impulsado por eventos?Asume que los mensajes pueden entregarse más de una vez y diseña consumidores que deduplicuen. Una práctica común es almacenar el ID del evento (o una clave de negocio para el paso) y ignorar repeticiones para que un replay no dispare la misma acción dos veces.
¿Qué debe incluir un rastro de auditoría para flujos de larga duración?Captura una línea de tiempo de hechos: actor, marca de tiempo, la entrada en ese momento, el resultado y la versión de la regla o política usada. Además, asigna un único ID de caso o correlación a todo lo relacionado con ese proceso para que soporte pueda responder “¿dónde está atascado?” sin buscar en logs no relacionados.
¿Cuál es un modelo de datos práctico para aprobaciones que no se vuelva un desastre cuando crecen las reglas?Mantén un único registro de solicitud como “caso”, guarda las decisiones por separado y conduce los cambios de estado mediante transiciones persistidas que se puedan reproducir. En herramientas no-code como AppMaster, puedes modelar los datos en PostgreSQL e implementar la lógica visualmente, lo que ayuda a mantener aprobaciones, reintentos y campos de auditoría consistentes en la app.
27 ene 2026
8 min
26 ene 20268 min
21 ene 20268 minExperimente con AppMaster con plan gratuito.
Cuando esté listo, puede elegir la suscripción adecuada.
