Online ou assíncrono? Como escolher a forma de integrar os sistemas

Imagine uma quinta-feira de fechamento de mês. A área de operações da empresa sobe um arquivo com 50.000 endossos para ajustar a tarifa da carteira. O portal os recebe e os envia, o mais rápido que pode, ao sistema central. Em poucos minutos o core começa a demorar. Depois deixa de responder. Os agentes que emitiam apólices novas naquele mesmo momento veem telas congeladas, e ninguém sabe quais dos 50.000 endossos foram aplicados e quais não.

Ninguém errou no código: escolheu-se, sem dizer, uma só forma de integrar (a chamada online) para um trabalho que pedia outra. Este artigo é para quem responde pela operação ou pela tecnologia em uma empresa regulada ou de varejo: são três perguntas, em ordem.

Integrar não é «conectar sistemas». É decidir como o negócio se comporta quando um deles demora, cai ou recebe dez vezes mais trabalho que o habitual.

Primeira pergunta: a resposta é necessária neste instante, ou pode esperar?

Faça-a por processo, não por empresa.

• Online (síncrono): quem pede fica esperando a resposta para poder continuar. Uma cotação na tela: a pessoa não consegue avançar sem o preço. É uma ligação telefônica.
• Assíncrono: quem pede deixa o trabalho, recebe um aviso de recebimento e segue com o que estava fazendo; o outro sistema termina no próprio ritmo e avisa. Uma emissão de apólice ou o timbrado (certificação fiscal) de uma nota: o importante é que seja bem feito e que se saiba em que estado está, não que aconteça no mesmo segundo. É um trâmite no balcão.

Quatro critérios:

1. Há uma pessoa olhando a tela, esperando? Se sim, e a resposta é curta, tenda ao online.
2. O trabalho demora mais que a paciência dessa pessoa? Segundos longos, minutos ou horas: assíncrono.
3. O outro sistema aguenta o volume no pior momento? Se ele se satura com um pico, uma chamada online arrasta consigo o canal que depende dele. Assíncrono.
4. Depende de um terceiro que pode demorar ou falhar? (um banco, a autoridade fiscal, um fornecedor). Assíncrono, e com um número de acompanhamento.

Regra prática: o que decide uma tela vai online; o que movimenta dinheiro, documentos ou estoque costuma ir assíncrono.

Se é online: REST ou gRPC?

A decisão é técnica; o critério, da diretoria:

• REST (estilo de API sobre HTTP, quase sempre em JSON) quando pesa mais a compatibilidade com quem chama (um parceiro, um app, um fornecedor) ou que qualquer pessoa possa testar e depurar com facilidade. É o idioma comum da internet: quase toda ferramenta o entende. Também pode ter contratos versionados.
• gRPC (chamada de procedimento remoto de alto desempenho, com contrato em Protobuf) quando um contrato estrito, clientes gerados a partir dele, transmissão contínua ou um desempenho medido justificam que quem chama o suporte; por isso costuma aparecer entre sistemas próprios, onde ambas as pontas o falam.

Diretriz frequente, não regra: REST para fora, gRPC entre sistemas próprios. O detalhe está no artigo «REST ou gRPC: quando convém cada um, e por que o core da empresa não fala nenhum dos dois» (/blog/rest-ou-grpc-quando-convem-cada-um).

Se é assíncrono: qual sabor?

Para esta decisão convém distinguir seis opções frequentes, que podem ser combinadas; a literatura de mensageria empresarial (Hohpe e Woolf) e a documentação dos grandes provedores de nuvem [1][2] descrevem muitas mais. Nenhuma é «a boa»: cada uma resolve um problema diferente.

Aviso de retorno: «avisamos com o protocolo»

Use quando o trabalho demora segundos ou minutos e quem pediu pode receber avisos. O sistema receptor responde de imediato «recebido, o protocolo é 4821» e põe-se a trabalhar. Quando termina, avisa de volta com o protocolo. Em termos técnicos, o resultado volta por meio de um callback; se é entregue por HTTP a um endereço registrado, costuma chamar-se webhook.

O protocolo é o número de acompanhamento que associa cada resposta à solicitação correspondente (identificador de correlação [3]). Sem protocolo, um aviso é um papel sem dono.

Consulta por estado: «volte com o protocolo e pergunte»

Use quando quem pediu não pode receber avisos (firewall, aplicativo móvel, terceiros com restrições). Volta-se com o protocolo e pergunta-se «já está?» de tempos em tempos.

A documentação da Microsoft o descreve assim: a resposta inicial é um «aceito» (código HTTP 202) que indica onde consultar, e a consulta devolve estados como pendente, em andamento, bem-sucedido ou falho [4]. Funciona onde o aviso não chega, e propõe exigir uma chave por solicitação para não processá-la duas vezes [4].

Fila: a fila de trabalhos

Use quando o sistema que recebe tem um limite de ritmo e quem envia pode produzir muito mais. Quem envia deixa o trabalho e se retira; quem processa o pega no próprio ritmo. É, sobretudo, um amortecedor: a documentação da Microsoft o chama Queue-Based Load Leveling e o descreve como um buffer entre quem pede e o serviço, que suaviza cargas intermitentes que poderiam fazer o serviço falhar [5]. Para mais velocidade somam-se consumidores sobre a mesma fila (Competing Consumers), se os trabalhos são independentes [6].

Cenário (números ilustrativos, sem cliente). Um portal recebe 50.000 endossos; o core aguenta 20 por minuto. Sem amortecedor, o portal empurra tudo de uma vez e o core se satura. A 20 por minuto, o tempo teórico é de cerca de 42 horas (50.000 ÷ 20 = 2.500 minutos); o real depende de validações, reenvios e janelas operacionais. A fila regula a entrada; o protocolo por lote, o painel de andamento e os alertas são desenhados à parte, e em troca não há um core fora do ar em horário de pico.

A fila não torna o core mais rápido: faz com que o limite dele deixe de ser uma surpresa. Não convém se for necessária resposta imediata nem se o volume é baixo e estável [5].

Evento ou tópico: o aviso pelo alto-falante

Use quando um mesmo fato deve mover várias coisas ao mesmo tempo: documentos, aviso ao cliente, CRM, fraude. Os anteriores vão de um para um; o evento, de um para muitos. Em vez de dizer a um sistema «faça isto», quem vive o fato o anuncia: «apólice emitida», «pagamento aplicado». Todos os inscritos recebem uma cópia, e quem o emite não sabe quantos são. Na literatura de mensageria, é a diferença entre um canal ponto a ponto (um receptor) e um de publicação-assinatura (todos os interessados) [7].

O custo: tudo é eventualmente consistente; durante um tempo, uns sistemas sabem da notícia e outros não. Não serve se for necessária uma única transação atômica entre emissor e receptores [8].

Fluxo de eventos de alto volume: a fita que se pode rebobinar

Use quando os eventos são muitíssimos, contínuos, e importa conservá-los para relê-los. O Apache Kafka o define como capturar eventos em tempo real, armazená-los de forma durável para consultá-los depois, e processá-los tanto no momento quanto retrospectivamente [9]. A imagem: uma fita de fatos que várias equipes leem no próprio ritmo, enquanto durar o período de retenção configurado [9].

Faz sentido para telemetria, estoque ou fraude; não para um pedido pontual, pois é maquinaria que alguém deve operar. Segundo a documentação de cada provedor, as garantias de entrega, ordem, duplicidades e reprodução variam por produto e configuração [10][11].

Troca por tabelas ou arquivos: quando o outro sistema não consegue receber mais nada

Use quando o sistema de destino é um core antigo que não sabe falar nenhum dos idiomas anteriores. Um sistema assim costuma ter quatro limitações:

• Não expõe interfaces para que outros lhe peçam coisas, e tampouco avisa quando algo muda no interior dele.
• Só aceita dados em uma zona de troca: tabelas ou arquivos combinados, onde se deixa a informação.
• Os processa no próprio ritmo, muitas vezes em lotes, disparando um processo próprio que os pega, os executa e escreve o resultado.
• Suporta pouca carga, e a resposta chega quando esse processo termina, não quando é solicitada.

A zona de troca é um balcão de formato fixo: ali se deixa cada instrução com o protocolo próprio, e o core deixa o resultado no mesmo lugar. O mérito: não se escreve nas tabelas internas do core. O custo: alguém deve vigiar a zona e a resposta demora o que o lote demorar.

Sobre essa zona vai uma camada anticorrupção: um tradutor dos contratos modernos para os campos e ritmos que o core entende [12]. Assim se moderniza por etapas (Strangler Fig) enquanto o core segue operando [13].

Recebido não é processado

Se há uma única ideia a levar deste artigo, que seja esta: um aviso de recebimento não é uma confirmação de resultado. Com frequência se acredita que, porque chegou o aviso, o que foi enviado ficou resolvido.

Há três níveis de resposta, e convém saber em qual está cada processo da empresa:

SPEI é o sistema de pagamentos eletrônicos interbancários do México; CEP, o comprovante eletrônico de pagamento que o Banxico (banco central do México) emite; CFDI, a nota fiscal eletrônica mexicana; SAT, a autoridade fiscal do México.

Só o terceiro nível diz se a nota existe, se o pagamento chegou ou se o pedido será cumprido. O Banxico o ilustra: liquidado significa que o SPEI liquidou e avisou a instituição receptora, e o CEP faz constar o crédito na conta beneficiária [16].

A indústria já separa receber de processar. O HTTP define o código 202 como «aceito para processamento, mas o processamento não foi concluído»; a solicitação poderia nunca ser executada e o protocolo não tem como reenviar depois o estado [17]. No AS2, o padrão de intercâmbio de documentos entre empresas, o exemplo oficial de recibo assinado traz este comentário: «Isto não é garantia de que a mensagem tenha sido processada por completo ou entendida pelo tradutor receptor» [18].

O que vimos. Em uma integração de pedidos entre dois sistemas corporativos que revisamos, de umas oito chamadas, duas devolviam o identificador do documento criado; as outras seis, só um aviso de recebimento. Os erros chegavam por e-mail da área receptora, uns três dias depois. No mesmo lote havia mais de dez casos idênticos que ninguém tinha visto: só se descobrem os que alguém revisa por acaso, e o resto é indistinguível dos que saíram bem. É uma medição de um único caso, não um número da indústria. O mais barato que funcionou: comprovar que a referência que retorna corresponde ao registro correto. Em 234 registros, não deu um único falso alarme.

O que pedir, segundo o sabor:

• Em todos: um protocolo por operação que viaje de ida e volta, para associar cada resultado à solicitação correspondente [3].
• Aviso de retorno: que avise o resultado; um «terminei» sem dizer se foi aplicado é outro aviso de recebimento.
• Consulta por estado: um estado claro por protocolo (pendente, em andamento, bem-sucedido ou falho) e, se falhou, o motivo [4].
• Fila: que as mensagens que falham fiquem separadas para revisão, com a origem anotada [15].
• Tabelas ou arquivos: uma linha de resultado para cada registro enviado.

E mais duas defesas. Um estado explícito para o que não retornou («sem confirmar desde as 10h40»): o pior não é o erro, é não saber. E uma conciliação periódica que compare o enviado com o confirmado, com alarme para o que não retornou a tempo; assim o silêncio vira uma tarefa com responsável.

Problema do setor, primeira pergunta, sabor

Guia de conversa, não receita: o normal é combinar sabores.

Os riscos, em linguagem de negócio

Um sabor assíncrono não elimina os problemas: muda-os de lugar. Cinco para a mesa.

• «Já foi cobrado duas vezes». A maioria das filas entrega cada mensagem ao menos uma vez: pode chegar repetida. A Microsoft pede que processá-la várias vezes dê o mesmo resultado, para evitar «registros duplicados ou cobranças repetidas» [5]: cada instrução leva uma chave única e o sistema registra quais já processou.
• A ordem. Quando vários consumidores pegam da mesma fila, não há garantia de que os trabalhos terminem na ordem em que entraram [5][6]. Se «cancelar a apólice» chega antes de «emitir a apólice», há um problema. Defina a chave de ordem do negócio (apólice, pagamento, sinistro) e respeite-a onde importa.
• Reenvios sem freio. Um erro passageiro merece outra tentativa; uma rejeição funcional («conta inexistente») não se resolve repetindo-a. O recomendado é separá-la em uma fila de exceções e monitorá-la [5][6].
• Não saber em que estado está algo. É o risco da seção anterior; em eventos convém, além disso, um identificador que percorra cada operação de ponta a ponta [8].
• Cada um vê uma versão diferente, por um tempo [8]. Decida de antemão quem é o dono do dado final e como se concilia uma operação pela metade.

O formato dos avisos é um acordo que se versiona; o CloudEvents exige que source mais id seja único por evento, o que ajuda a detectar reenvios [14].

Cinco perguntas para o próximo comitê

1. Que decisões exigem resposta imediata e quais podem ser resolvidas com um protocolo?
2. Qual é o ritmo máximo que o core da empresa sustenta, e o que acontece se chega dez vezes esse volume?
3. Quem é o dono do estado final de cada operação, e como se concilia uma que ficou incompleta?
4. Como comprovamos que uma nova tentativa não duplica um pagamento, uma apólice, um CFDI ou uma movimentação?
5. Do que enviamos ontem, quais operações têm confirmação de resultado (aplicada ou rejeitada) e quais só um aviso de recebimento?

Se em duas ou mais a resposta é «não sei», ali pode estar o risco.

Por onde começar esta semana

Anote os processos mais importantes da empresa (emissão, cobrança, timbrado, estoque), qual sistema responde a cada um e quanto trabalho por minuto suporta; e se quem o inicia precisa da resposta já ou bastaria um protocolo. Ficará claro onde se usa uma chamada online para um trabalho que pedia uma fila.

Depois, tome uma interface e conte quantas operações enviadas ontem têm confirmação de resultado, não só aviso de recebimento.

O que a Hábil faz

A Hábil é uma consultoria mexicana de engenharia, fundada em 2006, que trabalha entre os sistemas que uma empresa já tem e os canais que precisa abrir. Veja a página Unificar a operação e os canais.

A primeira conversa é sem custo: parte de um mapa das integrações atuais e de onde a operação poderia perder dinheiro, tempo ou evidência. Escreva para nós pelo WhatsApp.

As descrições de serviços de provedores refletem a documentação deles em 6 de outubro de 2026; são atribuições do provedor, não medições próprias.