Compare fluxos orientados a eventos vs APIs request-response para processos longos, focando em aprovações, timers, tentativas e trilhas de auditoria em apps de negócio.
Um processo é “de longa duração” quando não pode ser concluído em um passo rápido. Pode levar minutos, horas ou dias porque depende de pessoas, tempo ou sistemas externos. Tudo que tenha aprovações, repasses e espera entra nessa categoria.
É aí que o pensamento simples de API request-response começa a falhar. Uma chamada de API foi feita para uma troca curta: envie uma requisição, receba uma resposta, siga em frente. Tarefas longas são mais como uma história com capítulos. Você precisa pausar, lembrar exatamente onde está e continuar depois sem adivinhar.
Você vê isso em apps de negócios do dia a dia: aprovações de compras que precisam do gerente e da área financeira, integração de funcionários que espera checagens de documentos, reembolsos dependentes de um provedor de pagamento, ou pedidos de acesso que devem ser revisados e depois aplicados.
Quando equipes tratam um processo longo como uma única chamada de API, alguns problemas previsíveis aparecem:
Um cenário concreto: um funcionário solicita acesso a um software. O gerente aprova rápido, mas o time de TI precisa de dois dias para provisionar. Se o app não conseguir manter o estado do processo, enviar lembretes e retomar com segurança, você terá acompanhamentos manuais, usuários confusos e trabalho extra.
Por isso a escolha entre fluxos orientados a eventos vs APIs request-response importa para processos empresariais de longa duração.
A comparação mais simples se resume a uma pergunta: o trabalho termina enquanto o usuário espera, ou continua depois que ele sai?
Uma API request-response é uma troca única: uma chamada entra, uma resposta sai. Cabe a trabalhos que terminam rápido e previsivelmente, como criar um registro, calcular um orçamento ou checar estoque. O servidor faz o trabalho, retorna sucesso ou falha, e a interação acaba.
Um fluxo orientado a eventos é uma série de reações ao longo do tempo. Algo acontece (um pedido é criado, um gerente aprova, um timer expira) e o workflow avança para a próxima etapa. Esse modelo serve a trabalhos que incluem repasses, espera, tentativas e lembretes.
A diferença prática é o estado.
Com request-response, o estado frequentemente vive na requisição atual mais a memória do servidor até a resposta ser enviada. Com fluxos orientados a eventos, o estado precisa ser armazenado (por exemplo em PostgreSQL) para que o processo possa retomar depois.
O tratamento de falhas também muda. Request-response geralmente lida com falhas retornando um erro e pedindo ao cliente para tentar novamente. Workflows registram a falha e podem tentar de novo com segurança quando as condições melhoram. Eles também podem registrar cada passo como um evento, o que facilita reconstruir o histórico.
Um exemplo simples: “Enviar relatório de despesas” pode ser síncrono. “Obter aprovação, esperar 3 dias, lembrar o gerente, então pagar” não é.
Aprovações são onde o trabalho de longa duração vira concreto. Um passo de sistema termina em milissegundos, mas uma pessoa pode responder em dois minutos ou dois dias. A escolha de projeto é modelar essa espera como um processo pausado, ou como uma nova mensagem que chega depois.
Com APIs request-response, aprovações muitas vezes assumem formas desconfortáveis:
Tudo isso pode funcionar, mas adiciona encanamento só para ligar “tempo humano” ao “tempo de API”.
Com eventos, a aprovação lê como uma história. O app registra algo como “ExpenseSubmitted”, e mais tarde recebe “ExpenseApproved” ou “ExpenseRejected”. O motor de workflow (ou sua própria máquina de estados) move o registro adiante somente quando o próximo evento chega. Isso bate com a forma como a maioria das pessoas já pensa sobre passos de negócio: submeter, revisar, decidir.
A complexidade aparece rápido com múltiplos aprovadores e regras de escalonamento. Você pode exigir gerente e financeiro, mas permitir que um gerente sênior sobreponha. Se não modelar essas regras claramente, o processo fica difícil de raciocinar e ainda mais difícil de auditar.
Um padrão prático é manter um único registro de “solicitação” e armazenar decisões separadamente. Assim você consegue suportar vários aprovadores sem reescrever a lógica núcleo.
Capture alguns dados como registros de primeira classe:
Qualquer que seja a implementação, sempre armazene quem aprovou o quê, quando e por quê como dados, não como uma linha de log.
Esperar é onde tarefas longas começam a ficar bagunçadas. Pessoas almoçam, agendas lotam e “vamos responder” vira “quem é o dono disso agora?” Essa é uma das diferenças mais claras entre fluxos orientados a eventos vs APIs request-response.
Com request-response, tempo é desconfortável. Chamadas HTTP têm timeout, então você não consegue manter uma requisição aberta por dois dias. Equipes normalmente acabam com padrões como polling, um job agendado que varre o banco de dados ou scripts manuais quando algo está atrasado. Isso pode funcionar, mas a lógica de espera fica fora do processo. Casos de canto são fáceis de perder, como o que acontece quando o job roda duas vezes, ou quando o registro mudou pouco antes do lembrete ser enviado.
Workflows tratam o tempo como um passo normal. Você pode dizer: espere 24 horas, envie um lembrete, então espere até 48 horas no total e escale para outro aprovador. O sistema mantém o estado, então prazos não ficam escondidos em um projeto separado de “cron + queries”.
Uma regra simples de aprovação poderia ser assim:
Depois que um relatório de despesas é submetido, espere 1 dia. Se o status ainda for “Pending”, avise o gerente. Depois de 2 dias, se ainda estiver pendente, realoque para o líder do gerente e registre a escalada.
O detalhe chave é o que fazer quando o timer dispara mas o mundo mudou. Um bom workflow sempre re-checa o estado atual antes de agir:
Tentativas (retries) são o que você faz quando algo falhou por razões fora do seu controle: gateway de pagamento com timeout, provedor de e-mail com erro temporário, ou seu app salva o passo A mas cai antes do passo B. O perigo é simples: você tenta de novo e faz a ação duas vezes.
Com request-response, o padrão comum é que o cliente chama um endpoint, espera e, se não obtiver sucesso claro, tenta novamente. Para tornar isso seguro, o servidor precisa tratar chamadas repetidas como a mesma intenção.
Uma correção prática é uma chave de idempotência: o cliente envia um token único como pay:invoice-583:attempt-1. O servidor armazena o resultado para essa chave e retorna o mesmo resultado para repetições. Isso evita cobranças em duplicidade, tickets duplicados ou aprovações repetidas.
Fluxos orientados a eventos têm outro tipo de risco de duplicação. Eventos frequentemente são entregues pelo menos uma vez (at-least-once), o que significa que duplicatas podem aparecer mesmo quando tudo está funcionando. Consumidores precisam deduplicar: registre o ID do evento (ou uma chave de negócio como invoice_id + step) e ignore repetições. Essa é uma diferença central nos padrões de orquestração: request-response foca em replays seguros de chamadas, enquanto eventos focam em replays seguros de mensagens.
Algumas regras de retry funcionam bem em qualquer modelo:
Tentativas devem ser explícitas no processo, não comportamento escondido. Assim você torna falhas visíveis e corrigíveis.
Uma trilha de auditoria é seu arquivo do “por quê”. Quando alguém pergunta “Por que essa despesa foi rejeitada?” você deve ser capaz de responder sem adivinhar, mesmo meses depois. Isso importa tanto em fluxos orientados a eventos quanto em APIs request-response, mas o trabalho fica diferente.
Para qualquer processo de longa duração, registre os fatos que permitem reproduzir a história:
Fluxos orientados a eventos podem facilitar auditoria porque cada passo naturalmente produz um evento como “ManagerApproved” ou “PaymentFailed”. Se você armazenar esses eventos com payload e ator, obtém uma linha do tempo limpa. O importante é manter eventos descritivos e guardá-los onde você possa consultar por caso.
APIs request-response ainda podem ser auditáveis, mas a história costuma ficar espalhada por serviços. Um endpoint registra “aprovado”, outro registra “pagamento solicitado” e um terceiro registra “retry succeeded”. Se cada um usar formatos ou campos diferentes, auditorias viram trabalho de detetive.
Uma correção simples é um “case ID” compartilhado (também chamado correlation ID). É um identificador que você anexa a toda requisição, evento e registro do banco para a instância do processo, como “EXP-2026-00173”. Assim você consegue traçar toda a jornada.
A melhor escolha depende de você precisar de uma resposta imediata ou de o processo continuar por horas ou dias.
Request-response funciona bem quando o trabalho é curto e as regras são simples. Um usuário submete um formulário, o servidor valida, salva dados e retorna sucesso ou erro. Também cabe ações claras e de passo único como create, update ou check permissions.
Começa a doer quando uma “única requisição” vira vários passos: esperar aprovação, chamar múltiplos sistemas externos, lidar com timeouts ou ramificações baseadas no que acontece a seguir. Você ou mantém uma conexão aberta (frágil), ou empurra espera e retries para jobs background difíceis de raciocinar.
Fluxos orientados a eventos brilham quando o processo é uma história ao longo do tempo. Cada passo reage a um novo evento (aprovado, rejeitado, timer disparado, pagamento falhou) e decide o que fazer depois. Isso torna mais fácil pausar, retomar, retry e manter uma trilha clara do porquê o sistema agiu assim.
Há trocas reais:
Um exemplo prático: um relatório de despesas que precisa de aprovação do gerente, depois revisão financeira e então pagamento. Se o pagamento falha, você quer retries sem pagar duas vezes. Isso é naturalmente orientado a eventos. Se for apenas “submeter despesa” com checagens rápidas, request-response geralmente basta.
Processos longos falham de maneiras chatas: uma aba do navegador fecha, um servidor reinicia, uma aprovação fica três dias pendente, ou um provedor de pagamento dá timeout. Projete pensando nesses atrasos desde o início, independentemente do modelo escolhido.
Comece definindo um pequeno conjunto de estados que você possa armazenar e retomar. Se você não consegue apontar o estado atual no banco de dados, não tem realmente um workflow retomável.
Para sobreviver a reinícios, persista o mínimo de dados necessários para continuar com segurança. Guarde o suficiente para re-executar sem adivinhar:
Se você consegue reconstruir “onde estamos” e “o que é permitido a seguir” a partir dos dados guardados, atrasos deixam de ser assustadores.
Processos longos frequentemente quebram só quando usuários reais aparecem. Uma aprovação leva dois dias, um retry dispara na hora errada e você acaba com pagamento em duplicidade ou trilha de auditoria incompleta.
Erros comuns:
Um exemplo simples: um relatório de despesas é aprovado no chat, um webhook chega atrasado e a API de pagamento é tentada novamente. Sem estado persistido e idempotência, o retry pode pagar duas vezes, e seus registros não explicarão claramente o porquê.
A maioria das correções é ser explícito:
Trabalho de longa duração é menos sobre uma chamada perfeita e mais sobre permanecer correto após atrasos, pessoas e falhas.
Escreva o que “seguro para continuar” significa para seu processo. Se o app reiniciar no meio, você deve conseguir retomar do último passo conhecido sem adivinhar.
Um checklist prático:
Um teste de sanidade: imagine que um provedor de pagamento deu timeout depois que você já cobrou o cartão. Seu desenho deve impedir cobrar duas vezes, ao mesmo tempo em que permite que o processo termine.
Cenário: um funcionário submete um recibo de táxi de $120 para reembolso. Precisa de aprovação do gerente em 48 horas. Se aprovado, o sistema paga ao funcionário. Se o pagamento falhar, ele tenta de novo com segurança e deixa um registro claro.
Com APIs request-response, o app costuma se comportar como uma conversa que precisa ficar checando. O funcionário toca em Submit. O servidor cria um registro de reembolso com status “Pending approval” e retorna um ID. O gerente recebe uma notificação, mas o app do funcionário geralmente precisa fazer polling para ver se algo mudou, por exemplo: “GET reimbursement status by ID.”
Para impor o prazo de 48 horas, você ou roda um job agendado que varre solicitações vencidas, ou armazena um timestamp de deadline e verifica durante os polls. Se o job atrasar, os usuários veem status desatualizado.
Quando o gerente aprova, o servidor muda para “Approved” e chama o provedor de pagamento. Se Stripe retornar um erro temporário, o servidor precisa decidir tentar agora, agendar uma nova tentativa ou falhar. Sem chaves de idempotência cuidadosas, um retry pode gerar um pagamento em duplicidade.
No modelo orientado a eventos, cada mudança é um fato registrado.
O funcionário submete, gerando um evento “ExpenseSubmitted”. Um workflow começa e espera por “ManagerApproved” ou por um evento timer “DeadlineReached” em 48 horas. Se o timer disparar primeiro, o workflow registra um resultado “AutoRejected” e o motivo.
Na aprovação, o workflow registra “PayoutRequested” e tenta o pagamento. Se Stripe der timeout, ele registra “PayoutFailed” com um código de erro, agenda um retry (por exemplo em 15 minutos) e só registra “PayoutSucceeded” uma vez, usando uma chave de idempotência.
O que o usuário vê permanece simples:
A trilha de auditoria lê como uma timeline: submitted, approved, deadline checked, payout attempted, failed, retried, paid.
Escolha um processo real e construa de ponta a ponta antes de generalizar. Aprovação de despesas, onboarding e tratamento de reembolsos são bons pontos de partida porque incluem passos humanos, espera e caminhos de erro. Mantenha o objetivo pequeno: um happy path e as duas exceções mais comuns.
Escreva o processo como estados e eventos, não como telas. Por exemplo: “Submitted” -> “ManagerApproved” -> “PaymentRequested” -> “Paid”, com ramificações como “ApprovalRejected” ou “PaymentFailed”. Quando você vê claramente os pontos de espera e efeitos colaterais, a escolha entre fluxos orientados a eventos vs APIs request-response fica prática.
Decida onde o estado do processo vive. Um banco de dados pode ser suficiente se o fluxo for simples e você conseguir garantir atualizações em um só lugar. Um motor de workflow ajuda quando você precisa de timers, retries e branching, porque ele controla o que deve acontecer a seguir.
Adicione campos de auditoria desde o primeiro dia. Armazene quem fez o quê, quando aconteceu e por quê (comentário ou código de motivo). Quando alguém perguntar “Por que esse pagamento foi re-tentado?” você quer uma resposta clara sem ter que vasculhar logs.
Se você estiver construindo esse tipo de workflow em uma plataforma no-code, AppMaster (appmaster.io) é uma opção onde você pode modelar dados em PostgreSQL e criar a lógica do processo visualmente, o que pode facilitar manter aprovações e trilhas de auditoria consistentes entre web e apps móveis.
When should I use request-response instead of an event-driven workflow?Use request-response quando o trabalho terminar rápida e previsivelmente enquanto o usuário espera, como criar um registro ou validar um formulário. Use um fluxo orientado a eventos quando o processo durar minutos ou dias, incluir aprovações humanas ou precisar de timers, tentativas e retomada segura após reinícios.
Why do long-running processes break when built like a single API call?Tarefas longas não cabem em uma única requisição HTTP porque conexões expiram, servidores reiniciam e o trabalho depende de pessoas ou sistemas externos. Se você tratar tudo como uma única chamada, normalmente perde estado, cria duplicações ao tentar novamente e acaba com scripts de background espalhados para lidar com esperas.
How do I make a long-running process resumable after a restart?Um bom padrão é persistir um estado claro do processo no banco de dados e avançar esse estado apenas por transições explícitas. Armazene o ID da instância do processo, o status atual, quem pode agir a seguir e os timestamps-chave para que você possa retomar com segurança após deploys, falhas ou atrasos.
What’s the cleanest way to handle human approvals?Modele aprovações como uma etapa pausada que retoma quando chega uma decisão, em vez de bloquear ou ficar em polling constante. Registre cada decisão como dados (quem decidiu, quando, aprovar/rejeitar e motivo) para que o fluxo possa avançar de forma previsível e você possa auditar depois.
Is polling for approval status a bad idea?O polling pode funcionar em casos simples, mas adiciona ruído e atrasos porque o cliente fica perguntando “já terminou?”. Um padrão melhor é enviar uma notificação quando houver mudança e deixar o cliente atualizar sob demanda, enquanto o servidor é a fonte de verdade do estado.
How should I implement reminders, deadlines, and escalations?Trate o tempo como parte do processo: armazene deadlines e horários de lembrete, e ao disparar um timer sempre verifique o estado atual antes de agir. Assim você evita enviar lembretes depois que algo já foi aprovado e mantém as escaladas consistentes mesmo se jobs rodarem atrasados ou duas vezes.
How do I prevent double payments or duplicate emails when retries happen?Comece com chaves de idempotência para qualquer efeito colateral (cobrar um cartão, enviar um e-mail) e armazene o resultado para essa chave. Assim, repetir a mesma intenção retorna o mesmo resultado em vez de executar a ação novamente.
How do I handle duplicate events in an event-driven system?Pressuponha que mensagens possam ser entregues mais de uma vez e faça consumidores que deduplicam. Uma abordagem prática é armazenar o ID do evento (ou uma chave de negócio para a etapa) e ignorar repetidos para que um replay não dispare a mesma ação duas vezes.
What should an audit trail include for long-running workflows?Capture uma linha do tempo de fatos: ator, timestamp, o input disponível então, o resultado e a versão da regra/política usada. Também use um único case ID ou correlation ID para tudo relacionado ao processo, assim o suporte pode responder “onde está preso?” sem vasculhar logs desconexos.
What’s a practical data model for approvals that won’t get messy as rules grow?Mantenha um registro principal do pedido como o “caso”, armazene decisões separadamente e conduza mudanças de estado por transições persistidas que possam ser reproduzidas. Em ferramentas no-code como AppMaster, você pode modelar dados em PostgreSQL e implementar a lógica de etapas visualmente, o que ajuda a manter aprovações, tentativas e campos de auditoria consistentes.
27 de jan. de 2026
8 min
26 de jan. de 20268 min
21 de jan. de 20268 minExperimente o AppMaster com plano gratuito.
Quando estiver pronto, você poderá escolher a assinatura adequada.
