Integrações precisam ser projetadas para falhar bem
A chamada HTTP feliz é a parte simples. Em produção surgem timeouts, duplicidade, indisponibilidade, dados fora do formato, reprocessamento e mudanças de contrato. A arquitetura precisa prever essas situações desde o início.
Em fluxos críticos, usamos idempotência, retentativas com limite, filas, dead-letter queues, correlação e métricas para que uma falha seja visível e recuperável.
- APIs REST e SOAP
- Webhooks e callbacks de pagamento
- Kafka e mensageria assíncrona
- Integrações com ERP, CRM e serviços financeiros
- Sincronização e migração de dados entre bancos
Java e Spring Boot para integrações empresariais
Java e Spring Boot são uma combinação madura para serviços com regras complexas, integração com ecossistemas corporativos, segurança, bancos relacionais e mensageria. Quando o ambiente já utiliza Java, manter a integração no mesmo ecossistema também reduz custo de suporte e curva de aprendizado.
Quando outro stack é mais adequado, a solução pode usar Go, PHP, Node.js ou Python. O contrato entre sistemas deve ser mais estável do que a linguagem usada para implementá-lo.
Observabilidade para saber onde a transação parou
Uma integração que falha sem evidência cria suporte caro. Por isso, eventos importantes recebem identificadores de correlação e logs com contexto suficiente para reconstruir o caminho de uma transação sem expor dados sensíveis.
Onde integração costuma falhar
A parte cara de integrar quase nunca é escrever a chamada. É o comportamento do outro lado: o ERP que responde em XML de duas décadas atrás, o gateway que muda o contrato sem aviso, a prefeitura com layout próprio de NFS-e e o serviço que devolve HTTP 200 com erro dentro do corpo da resposta.
Por isso o desenho parte do princípio de que a integração vai falhar em algum momento. O que diferencia uma integração madura de uma frágil é o que acontece quando isso ocorre: reprocessamento, fila, alerta e registro suficiente para descobrir a causa sem precisar reproduzir o problema.
- Tentativa automática com espera crescente e limite de repetição
- Fila e reprocessamento para não perder transação em indisponibilidade
- Idempotência: reenviar a mesma operação não duplica o efeito
- Conciliação periódica entre os dois lados da integração
- Alerta com limiar acordado e registro rastreável de cada chamada
Camada anticorrupção: proteger o seu sistema do sistema alheio
Quando o modelo de dados de um fornecedor vaza para dentro do seu sistema, qualquer mudança dele vira mudança sua. A camada anticorrupção resolve isso: uma fronteira que traduz o formato externo para o seu vocabulário interno e isola o resto da aplicação.
O custo é uma camada a mais de código. O retorno é poder trocar de gateway, de ERP ou de transportadora sem reescrever regra de negócio — e conseguir testar a integração sem depender do ambiente do outro lado estar no ar.
Perguntas frequentes
Vocês integram sistemas legados sem API?
Sim. Primeiro avaliamos as interfaces disponíveis. Dependendo do sistema, a integração pode usar banco, arquivos, filas, serviços SOAP, automação controlada ou uma camada intermediária.
É possível integrar Pix, gateways e emissão fiscal?
Sim, desde que o provedor disponibilize uma interface suportada. Webhooks, idempotência, conciliação e tratamento de falhas fazem parte do desenho.
E se o sistema do outro lado sair do ar?
A integração é desenhada supondo que isso vai acontecer: a operação entra em fila, é reprocessada quando o serviço volta e gera alerta se passar do limite acordado. Nada se perde silenciosamente.
Vocês integram com ERP que não tem API moderna?
Sim. Boa parte do trabalho é exatamente com serviços SOAP antigos, arquivos posicionados, exportação agendada e banco intermediário. A camada de tradução isola essa complexidade do resto do sistema.