Software e IA para executivos · Capítulo 13 de 41 · 6 min
Responder ao cliente agora e deixar o resto para depois
Decida o que precisa acontecer antes de o cliente ver a confirmação e o que pode esperar, sem prender a tela dele.
Este capítulo faz parte do curso gratuito Software e IA para executivos.
Aprovar uma fila entre a tela do pedido e as integrações decide o que o cliente vê quando um parceiro cai: erro na hora, ou confirmação normal enquanto o time resolve depois. Fila é a lista de trabalhos aceitos agora e executados depois, fora da espera do cliente.
Quando tudo acontece dentro do mesmo pedido do cliente, o tempo da tela vira a soma de todas as peças. O componente mais lento da cadeia (a peça do sistema que mais demora) passa a definir o produto inteiro.
A emissão da nota, o e-mail de confirmação e a integração com o parceiro entram nessa soma. Basta um parceiro fora do ar para o cliente ver um erro em algo que já tinha dado certo.
Fácil de descrever e difícil de aceitar, a separação tem três passos: a tela grava o pedido, responde ao cliente e enfileira o resto do trabalho. Um processo de fundo, chamado worker, executa depois, com nova tentativa e isolamento.
O que muda para você é o significado da confirmação. A tela deixa de dizer que tudo terminou e passa a dizer que o pedido foi aceito.
Os mecanismos têm nomes diferentes porque dão garantias diferentes. A fila entrega cada mensagem a um trabalhador só, e o pub/sub, que publica para vários inscritos ao mesmo tempo, serve para avisar. A coluna que decide a compra é a garantia de entrega, ao lado do custo de operar aquilo todo dia.
Mecanismos assíncronos e a garantia que cada um dá
| Mecanismo | Caso de uso | Garantia | Complexidade operacional |
|---|---|---|---|
| Queue, como BullMQ ou SQS | Job em background, e-mail, geração de PDF | At-least-once | Baixa |
| Event bus, como Kafka ou Kinesis | Stream de eventos, replay, analytics | Exactly-once, com cuidado | Alta |
| Pub/Sub, como Redis ou Google Pub/Sub | Notificação fan-out, baixa latência | At-most-once por padrão | Média |
| Orchestrator, como Temporal | Workflow longo, saga, retry com estado | Configurável | Alta |
| Execução durável, como Trigger.dev, Inngest ou Vercel Workflow | Tarefa longa que precisa retomar do ponto onde parou | Retomada de estado, com repetição possível de cada passo | Média |
At-least-once é o padrão da maioria das filas, e a consequência prática é que o consumidor precisa ser idempotente. Sem isso, o cliente recebe o mesmo e-mail duas vezes na primeira falha de rede. A última linha é a categoria que cresceu em 2026 com o agente de IA que roda por minutos: fila resolve desacoplamento, execução durável resolve retomada de estado (Trigger.dev, changelog da versão 4.5.0, 02/07/2026).
A lista do que hoje roda dentro da tela do cliente, com uma coluna ao lado do que aconteceria se aquilo atrasasse 30 segundos, separa o que pode esperar do que não pode.
O que puder atrasar sem prejuízo sai da espera e vai para a fila. O que não puder fica, e vira requisito de disponibilidade no contrato do fornecedor.
A confirmação passa a dizer que o pedido foi aceito e gravado, não que a nota saiu e o parceiro recebeu a mensagem.
Transação de banco, o pacote de gravações que entra inteiro ou não entra, cobre só o que está dentro do banco. A fila e o parceiro ficam fora dela, e essa fronteira abre espaço para o pedido existir sem o evento correspondente, tema da terceira aula deste capítulo.
Antes da próxima reunião de arquitetura, peça a lista do que roda dentro da tela do cliente, com o tempo medido passo a passo. Marque o que pode terminar depois: nota, e-mail, integração com parceiro e atualização de relatório.
Escreva a frase que a confirmação passa a prometer e nomeie quem olha o que ficou parado. Trabalho fora da tela sem painel só aparece na reclamação do cliente.
Seu caderno neste capítulo
Abrir o caderno completoSelecione um trecho do capítulo para destacar ou anotar. Nos vídeos e áudios, use Anotar este momento. No teclado, selecione com Shift e as setas e use Alt+Shift+D para destacar ou Alt+Shift+N para anotar.
Salvo neste navegador. Entre na sua conta para levar o caderno a outros aparelhos.
Entre na sua conta para compartilhar o que aprendeu e convidar alguém para estudar com você.
Conexões deste capítulo
Veja o que estudar antes e para onde seguir depois, explore os conceitos e compare abordagens em outros cursos. Sugestões marcadas como “sugerido pelo grafo” vêm dos assuntos em comum, não do índice do curso.
Conceitos deste capítulo
O mesmo assunto em outros cursos
- Do Agile ao Agentic Operating ModelO contrato que você assina antes de delegar ao agenteExaminar conexões de O contrato que você assina antes de delegar ao agente
- Frontends com VibecodingDirigir o prompt e avaliar a entrega do agenteExaminar conexões de Dirigir o prompt e avaliar a entrega do agente
- SO nativo de IAPor que não automatizar aindaExaminar conexões de Por que não automatizar ainda
- Agentes de IA Autônomos: Do Conceito à ProduçãoLangGraph avançado (grafos cíclicos)Examinar conexões de LangGraph avançado (grafos cíclicos)
Voltar ao capítulo anterior: Ler o erro da API antes de culpar alguém ou repetir
Leve uma ideia para a prática
Escolha uma atividade no painel e volte a este curso quando quiser.
Atividades e evolução ficam reunidas no painel da sua conta.
Capítulos vizinhos em Software e IA para executivos
- 11Escolher o formato da integração olhando quem vai consumir
- 12Ler o erro da API antes de culpar alguém ou repetir
- 13Responder ao cliente agora e deixar o resto para depois
- 14Tentar de novo sem cobrar o cliente duas vezes
- 15Manter vários sistemas de acordo quando um deles cai