O que acontece quando você realmente tenta conectar dois sistemas que não foram feitos um pro outro
A gente fala muito em integração, mas raramente explica o que isso significa na prática sem parecer um manual de marketing. Integração é basicamente o processo de fazer duas ou mais aplicações trocarem dados e comandos entre si de forma automática, sem intervenção humana. Parece simples até o momento em que você leva isso para um ambiente de produção e descobre que o sistema A espera datas no formato ISO 8601 e o sistema B espera data como string "DD/MM/YYYY". É aí que a coisa começa a doer. No Brasil, quando você vê alguém perguntando
oque e integração
, geralmente tá lidando com algo do tipo: conectar um e-commerce ao sistema financeiro da empresa, ou fazer o ERP falar com a plataforma de frete, ou ainda sincronizar cadastros entre CRM e ferramenta de marketing. O conceito é o mesmo em todos os casos, só mudam as ferramentas e aComplexidade cresce exponencialmente quando uma das pontas é um sistema legado que foi escrito em 2008 por uma equipe que já não existe mais.Como funciona na prática: o básico que ninguém conta
O modelo mais comum que você vai encontrar no mercado é o de integração via API REST. Um sistema envia uma requisição HTTP para o outro, que responde com dados em formato JSON. A coisa toda roda sobre um protocolo que todo mundo já usa sem perceber: HTTP/HTTPS. O sistema integrador monta a URL, adiciona os headers necessários, sobretudo um token de autenticação se for o caso, e manda a requisição. O sistema receptor processa e devolve uma resposta com código de status e o payload. Tem também o modelo de filas, que é o que a gente usa quando a integração não pode ser síncrona. Você põe a mensagem numa fila (AWS SQS, RabbitMQ, Azure Service Bus, o que for) e o sistema consumidor lê de lá quando consegue. Isso resolve o problema de um dos lados estar fora do ar sem perder dados. Eu usei esse modelo numa integração entre um sistema de pedidos e um ERPLegado que tinha janelas de manutenção diárias de 30 minutos. Com chamada direta, a gente perdia 40% dos pedidos nesses horários. Com fila, o problema sumiu. As mensagens ficavam guardadas e eram processadas assim que o sistema voltava.
Existem ainda integrações por arquivo, que são as mais subestimadas do mercado. Você gera um CSV, XML ou TXT, sobe num SFTP ou numa pasta na nuvem, e o sistema receptor consome. Parece primitivo, mas funciona muito bem quando um dos lados não tem API ou quando o volume de dados é grande demais para transmitir em tempo real. Um cliente meu fazia integração por arquivo entre um sistema de folha de pagamento e o banco. Cada mês, 20 mil registros. API seria overengineering. O arquivo ia todo dia 5, o banco processava, e pronto.
A parte chata: o que quebra e como resolver
A maioria das integrações que eu vi dar problema não quebrou por falha técnica nos códigos. Quebrou por mudança não comunicada. O sistema B atualizou a versão da API e mudou o campo "cpf" para "documento", sem avisar ninguém. A integração continuou rodando por duas semanas gerando erros silenciosos porque o campo novo vinha como null e o sistema A simplesmente não registrava o dado. Levou 14 dias para alguém perceber porque o relatório de vendas estava com metade dos CPFs zerados. Isso me ensinou a implementar monitoramento ativo em todas as integrações que eu passo a mão. Não adianta só olhar o log de erro. Você precisa de métricas de sucesso e fracasso por chamada, alertas quando a taxa de erro sobe acima de 2% em 5 minutos, e dashboards que mostrem o volume de registros processados por hora. Se uma integração que processava 500 requisições por minuto de repente processa 12, você tem um problema e quer saber antes que o culpado apareça no Slack.
Um problema muito específico que eu encontrei foi com integrações que envolvem timestamps fuso horário. O sistema A rodava em UTC, o sistema B em Brasília. Quando você passa um timestamp de um lado pro outro sem converter, eventos que aconteceram às 23h no horário de São Paulo podiam ser registrados como 02h do dia seguinte em UTC. O resultado era relatórios com pedidos do dia anterior misturados com os do dia atual. A solução foi padronizar todos os timestamps em UTC durante o trânsito e converter só na camada de apresentação. Simples, mas só depois de gastar três dias rastreando a causa raiz.
Ferramentas e abordagens: qual escolher e quando
Se você tá começando e precisa integrar duas coisas simples, faz uma script em Python ou Node que chama as APIs direto. Não precisa de ferramenta nenhuma. Um script bem feito com retries, backoff exponencial e log estruturado resolve 80% dos casos do dia a dia. Eu tenho um repositório interno com templates que uso pra isso: handle de exceção, retry com backoff, log de request e response, e alertas via webhook quando algo falha repetidamente. Quando o cenário escala — múltiplas integrações, necessidade de orchestration, monitoring centralizado — aí entra em jogo ferramentas como Apache Camel, MuleSoft, Zapier, Make, ou n8n. O n8n eu recomendo fortemente para times pequenos que precisam de algo visual e flexível. Você monta os fluxos num editor gráfico, conecta em dezenas de serviços diferentes, e ainda roda self-hosted se quiser manter os dados na sua infraestrutura. Não é a solução mais robusta do mundo, mas pra integrar sistema de mailing com planilha do Google e um webhook de pagamento, é mais do que suficiente.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Para integrações empresariais complexas com múltiplos sistemas legados, o padrão enterprise é ESB ou iPaaS. Tools como Dell Boomi, MuleSoft Anypoint Platform, ou Azure Logic Apps. Essas soluções oferecem conectores prontos, transformação de dados, versionamento de API, e governança. O preço é alto e a curva de aprendizado também. Eu trabalhei num projeto onde migramos de integração pontual em scripts para um ESB centralizado. O ganho em governança foi real, mas o tempo de onboarding de um novo desenvolvedor no sistema passou de 2 dias para 3 semanas. Trade-off que vale a pena entender antes de decidir.
O que ninguém te conta sobre integração
Primeiro: a maior parte do trabalho não é codar a integração. É entender os dados que fluem, mapear campos, lidar com traduções e normalizações. Eu já passei uma semana inteira só discutindo com o time do sistema receptor o que significava "status do pedido" porque para eles "cancelado" era uma coisa e para nós era outra completamente diferente. Segundo: documentação nunca é suficiente. A API pode documentar todos os campos, mas existem comportamentos não documentados, limites de taxa escondidos, e comportamentos Edge que só aparecem em produção. O melhor documento que você pode ter é um conjunto de testes automatizados que cobrem os cenários que você já viu dar problema.
Terceiro: integração não termina quando o código é deployado. Ela precisa de operação. Monitoramento, tratamento de erros, rollback em caso de problemas, e um plano claro do que fazer quando uma das pontas cai. Minha regra prática é: se você não consegue diagnosticar e recuperar uma integração quebrada em 15 minutos, você não está pronto para colocar ela em produção. Quarto: versionamento é obrigatório. Se o sistema receptor mudar um campo que sua integração consome, você precisa de versionamento de API ou pelo menos de um período de coexistência onde ambas as versões funcionem. Sem isso, qualquer atualização no sistema B quebra seu sistema A sem aviso prévio, e você descobre isso quando o chefe liga perguntando por que os pedidos não estão entrando no ERP.
Quando integração NÃO é a solução
Às vezes a resposta certa é não integrar. Se você precisa de dados de um sistema pro outro uma vez por mês e o volume é baixo, um export manual ou um script que roda esporadicamente pode ser mais eficiente do que construir uma integração contínua. Integração contínua é investimento permanente: você ganha automação mas também herda complexidade operacional para sempre. Antes de construir, pergunte se a frequência e o volume realmente justificam. Outro caso em que integração direta não faz sentido é quando os dados são sensíveis e passam por várias camadas de compliance. LGPD, PCI DSS, normas setoriais. Às vezes é melhor usar um intermediary que já tenha certificações adequadas do que construir sua própria ponte e assumir a responsabilidade por cada ponto de falha.
Um exemplo concreto: o que eu fiz na semana passada
Tinha uma integração entre um sistema de gestão escolar e um gateway de pagamento. O sistema escolar enviava a cobrança, o gateway processava, e precisávamos atualizar o status na escola. Simples, certo? Errado. O gateway tinha rate limit de 50 requisições por segundo, e o sistema escolar fazia picos de 200 chamadas por segundo no início de cada mês, quando as matrículas são abertas. Chamada direta simplesmente não funcionava. A solução foi trocar de síncrono para assíncrono com fila. O sistema escolar empilha as cobranças numa fila SQS. Um worker consome a 50 mensagens por segundo, respeitando o rate limit do gateway. Quando o pagamento é confirmado, o gateway manda um webhook de volta, e outro worker atualiza o status na escola. Todo o fluxo é observável: métricas de fila, latência de processamento, taxa de erro por etapa. Demorou quatro dias pra colocar no ar, mas desde então funciona sem intervenção há meses.
O aprendizado principal foi: não tente forçar um padrão síncrono em um problema que exige assincronia. A tentação é sempre a mais óbvia. Mas a mais óbvia raramente é a certa quando o volume ou a confiabilidade entram na equação.
