“Precisamos disso em tempo real” parece um requisito claro até alguém perguntar quanto tempo pode passar entre uma venda e sua chegada ao sistema de operações. Segundos? Dez minutos? Basta estar lá antes de preparar as entregas? A resposta muda bastante a arquitetura, e chegar a um acordo pode exigir mais discussão do que conectar os aplicativos.
Comece por aí ao escolher entre eventos e processos agendados. Consultar o CRM a cada dez minutos e receber uma notificação quando a venda é confirmada podem atender a necessidades diferentes, ambas legítimas. As perguntas decisivas vêm depois: como saber que o trabalho terminou, o que fazer se uma notificação não chegar e como evitar que uma nova tentativa crie o mesmo pedido duas vezes?
O que um evento está informando
Um evento representa um fato: pedido confirmado, documento recebido ou solicitação encerrada. Os consumidores reagem conforme suas responsabilidades. Um processo agendado executa em horários definidos e verifica qual trabalho está disponível. A arquitetura orientada a eventos descrita pela Microsoft separa produtores, canais e consumidores. Essa divisão permite componentes independentes, mas exige decisões explícitas sobre entrega e processamento.
Um webhook é uma forma de notificar outro sistema por meio de uma requisição HTTP. Ele não garante, sozinho, armazenamento durável, repetição ou conclusão correta. Essas propriedades dependem do contrato do fornecedor e da arquitetura receptora. Da mesma forma, um agendamento não garante completude automaticamente. Uma consulta mal definida pode ignorar registros ou recuperá-los repetidamente. As duas abordagens precisam controlar o progresso.
Pergunte qual atraso é aceitável e o que acontece quando esse limite é ultrapassado. “Tempo real” expressa uma expectativa, mas não define um objetivo operacional. Transforme isso em um intervalo mensurável entre o fato original e o resultado necessário. Se a atualização pode esperar horas, lotes agendados podem ser mais simples. Se o valor diminui a cada minuto, notificações ajudam a reduzir a espera. Considere também o tempo de processamento dos consumidores e suas dependências.
Compare consultas sem novidades. Um monitoramento frequente pode consumir recursos mesmo quando nada mudou. Equilibre esse custo com o esforço necessário para operar um canal confiável de eventos. Inclua recuperação na comparação. Uma integração rápida que perde solicitações silenciosamente pode ser menos útil que outra mais lenta, mas capaz de verificar o trabalho completo.
Receber a mensagem é apenas o começo
Ao receber uma notificação, valide autenticidade, formato e tamanho. Defina quando confirmar o recebimento. Responder antes de registrar o trabalho de forma durável cria uma janela em que uma falha pode perder a solicitação.
Processar tudo antes de responder traz outro risco: operações demoradas podem ultrapassar o tempo de espera do emissor. Uma solução comum registra a entrada com segurança, confirma o recebimento e executa o trabalho depois. O contrato deve esclarecer o significado da confirmação. “Recebido” e “concluído” são estados diferentes. Confundi-los pode deixar os sistemas aparentemente saudáveis enquanto o processo do cliente continua incompleto.
Disponibilize o status para quem responde pelo caso completo, em vez de mantê-lo apenas em registros técnicos do transporte.
Duas vezes, ou fora de ordem
Alguns mecanismos podem entregar a mesma mensagem mais de uma vez. O consumidor deve verificar se o identificador do evento ou a operação de negócio já foi processado. Isso é especialmente importante ao criar registros ou enviar comunicações. Não presuma uma ordem global de chegada. Uma atualização posterior pode ser recebida antes de outra anterior. Use versões da origem quando disponíveis e defina como descartar mudanças antigas ou consultar o estado atual.
Evite prometer efeitos únicos de ponta a ponta sem verificar todas as dependências. Eliminar duplicações na entrada não impede automaticamente uma chamada externa repetida depois de uma resposta incerta. Nas ações importantes, determine como investigar o resultado antes de repetir. Essa escolha deve fazer parte do desenho, não ser improvisada durante um incidente.
Três equipes e um pedido pela metade
Imagine uma venda que precisa chegar à operação, ao faturamento e ao acompanhamento comercial. O produtor registra o pedido e emite um evento identificável; cada consumidor realiza sua parte sem esperar que todos concluam ao mesmo tempo. O desenho parece promissor. A dificuldade aparece quando a operação já reservou trabalho, mas o faturamento está indisponível há vinte minutos.
Repetir todo o percurso seria uma recuperação ruim se reservasse novamente o que já foi reservado. Nesse desenho hipotético, a etapa de faturamento permanece pendente enquanto as ações confirmadas mantêm seu estado. Alguém precisa enxergar que o pedido está parcialmente processado, há quanto tempo aguarda e o que isso significa para a próxima atividade. Conforme a regra de negócio, pode ser necessário avisar alguém ou suspender uma etapa posterior.
Conectar consumidores não cria automaticamente essa visão completa. É preciso definir qual sistema a apresenta e quem assume quando uma etapa ultrapassa o prazo. Caso contrário, cada equipe pode ter um componente tecnicamente correto enquanto o cliente continua sem uma explicação útil sobre o pedido.
Por que a verificação periódica continua útil
Notificações podem se perder por configuração incorreta, indisponibilidade ou garantias limitadas de entrega. Um processo agendado de reconciliação pode comparar registros e localizar diferenças. Isso não significa executar o mesmo trabalho duas vezes sem controle. Os dois caminhos devem utilizar identificadores e regras de deduplicação compatíveis. A reconciliação verifica o ocorrido e recupera ausências de maneira deliberada.
Combinar notificações rápidas com verificações periódicas pode ser adequado quando a empresa precisa de agilidade e completude. Defina como diferenciar atraso normal de um caso realmente ausente. A própria reconciliação deve registrar o que verificou, quais divergências encontrou e quais ações corretivas realizou.
Um contrato que os consumidores entendam
Um evento precisa ter significado estável. Documente o que representa, qual identificador utiliza, quando é emitido e quais campos são obrigatórios. Evite dependências de detalhes internos que o produtor pode alterar sem aviso.
Escolha entre transportar os dados necessários ou apenas referências para consultas posteriores. Incluir dados reduz consultas, mas aumenta duplicação e volume transportado. Usar referências cria uma dependência de disponibilidade e pode recuperar um estado mais recente. Decida conforme sensibilidade, tamanho, necessidade de reconstrução histórica e consistência. Teste compatibilidade antes de mudar o formato.
O que observar quando o trabalho atrasa
Na operação, acompanhe o atraso desde a origem até o resultado de negócio. Observe a idade das pendências, as falhas, as entregas repetidas e os casos aguardando intervenção. Um intermediário saudável informa pouco sobre a conclusão do faturamento. Limites de novas tentativas e um destino para mensagens não processáveis dão à equipe onde procurar; contexto suficiente permite corrigir e reexecutar sem duplicar ações concluídas.
Teste indisponibilidade, entradas duplicadas e fora de ordem, picos e consumidores retomando trabalho após uma parada. Depois volte ao pedido inicial de “tempo real”. Se o resultado pode aguardar o próximo lote e o volume permite, o agendamento pode bastar. Se os minutos mudam o valor da resposta, ou vários consumidores precisam reagir independentemente, eventos podem justificar o esforço operacional adicional.
Leve o prazo necessário e um exemplo do que acontece quando ele não é cumprido à DigitalCube. Um pedido que não chegou ao faturamento é mais concreto do que uma expectativa abstrata de rapidez. A arquitetura precisa ajudar a explicar onde ele está, inclusive quando uma das peças deixa de responder.