Itaú, iFood, Airbnb e outras grandes organizações resolveram integração financeira em escala sem substituir seus sistemas centrais de uma vez. O padrão comum é a modernização progressiva: uma camada de orquestração e eventos é posicionada na frente do sistema legado, que continua funcionando como livro-razão, enquanto novas aplicações interagem com essa camada intermediária. Isso é diferente de integração ponto a ponto, que funciona bem no começo e se torna insustentável conforme a organização escala.
O momento em que integração ponto a ponto para de funcionar
Todo sistema financeiro legado começou simples. O problema aparece quando a organização precisa crescer, lançar um novo produto, ou expandir para um novo mercado, e cada novo sistema que entra no ecossistema precisa se conectar a todos os que já existem. Isso é uma consequência de como a complexidade de redes se comporta. Conexões diretas entre sistemas crescem de forma desproporcional ao número de sistemas, não proporcional a ele.
O Itaú Unibanco viveu essa tensão de um jeito bem concreto. Presente em mais de 20 países e processando uma fração relevante das transações financeiras do Brasil, o banco tinha parte relevante de sua lógica de contas correntes presa a mainframes e rotinas antigas. Em vez de tentar substituir tudo de uma vez, o banco optou, em um projeto específico de modernização de contas correntes internacionais, por desenvolvimento interno usando arquitetura serverless (funções sob demanda e workflows orquestrados), concluindo a migração completa de contas e dados históricos em 15 meses, com custo 26 vezes menor do que as alternativas de mercado avaliadas. Antes de decidir construir, o banco avaliou por seis meses cinco fornecedores diferentes, e só optou pelo desenvolvimento próprio depois de constatar que a experiência prévia do time com arquitetura serverless já havia provado agilidade, baixo esforço de manutenção e baixo custo de operação.
Em uma iniciativa diferente, também documentada publicamente, o banco modernizou sua plataforma de consulta de extratos migrando 36 mil unidades de processamento virtual para a nuvem e desativando 93% do ambiente legado ao longo de dois anos, alcançando de 3,5 a 6,4 vezes de melhoria de performance e uma redução de 99% no tempo entre solicitar e entregar uma funcionalidade em produção. São dois projetos distintos, mas com a mesma lógica por trás: modernizar em fatias, não de uma vez.
Quando a automação isolada só move o problema para a etapa seguinte
Um erro comum é tratar automação e integração como sinônimos. O iFood viveu isso na prática, em duas frentes diferentes da mesma operação.
A primeira foi técnica: o middleware financeiro que sustentava repasses, comissões e conciliação de pagamentos era um sistema monolítico com forte acoplamento de banco de dados, e os horários de pico da operação (o “dinner rush”) geravam gargalos de processamento. A resposta não foi automatizar mais rápido dentro do mesmo monólito, foi decompor o sistema em microsserviços independentes, cada um responsável por seu próprio domínio e seu próprio banco de dados, comunicando-se de forma assíncrona por um barramento de eventos.
A segunda foi de processo: a gestão de documentos fiscais e contas a pagar dependia de intervenção manual pesada, e a empresa conseguia quitar menos de 70% das notas fiscais dentro do prazo contratual. A solução não foi automatizar o lançamento manual existente, foi integrar o ERP diretamente à captura de documentos fiscais nas fontes oficiais, validando, calculando imposto e lançando no sistema contábil sem intervenção humana. O resultado divulgado foi elevar a taxa de pagamento em dia para 99,97%, com redução de 80% no tempo que as equipes de atendimento gastavam respondendo fornecedores sobre pagamentos atrasados. A lição comum aos dois casos: automatizar uma etapa isolada dentro de um processo mal desenhado só transfere o atraso para a etapa seguinte. O ganho real apareceu quando o fluxo foi integrado de ponta a ponta.
Quando orquestrar é melhor do que codificar cada caso à mão
Uma das ilustrações mais claras de por que orquestração vence codificação ponto a ponto vem de fora do setor financeiro tradicional. O Airbnb precisava lançar métodos de pagamento locais em diferentes países, do Pix no Brasil a transferências bancárias digitais na Europa, mas cada método novo exigia desenvolvimento customizado do zero, tanto no aplicativo quanto no backend. Isso gerava duplicação de código e dificuldade real para lidar com fluxos assíncronos, como redirecionamento para outro aplicativo ou leitura de QR Code.
A resposta foi trocar código-a-cada-novo-método por configuração centralizada: um arquivo que serve como fonte única de verdade sobre elegibilidade, campos de entrada e regras de cada meio de pagamento, alimentando automaticamente tanto o backend quanto a interface do aplicativo. Lançar um método de pagamento novo passou a ser, na prática, uma alteração de configuração, não um projeto de desenvolvimento. O resultado divulgado foi a implantação de mais de 20 métodos de pagamento locais em 14 meses, cobrindo mais de 200 mercados, com observabilidade sendo ativada automaticamente a cada novo método publicado.
Nem toda resposta é orquestrar por cima do legado
Vale um contraponto importante, porque nem todo caso segue a mesma receita. A Natura enfrentou um problema diferente. Depois de sucessivas aquisições, a empresa operava com oito sistemas ERP de grande porte simultaneamente. Isso gerava silos contábeis, lentidão no fechamento financeiro e custo crescente de manter cada um vivo. Em vez de construir uma camada de tradução entre os oito sistemas, o que teria sido a resposta clássica de “orquestrar por cima do legado”, a empresa optou por consolidar tudo em uma única plataforma corporativa de ERP na nuvem. Desta forma, eliminou de vez a necessidade de tradução entre sistemas diferentes.
Isso não contradiz a lógica dos outros casos, complementa ela. Orquestração e desacoplamento resolvem bem o problema de conectar sistemas que precisam continuar existindo lado a lado. Quando o problema é ter sistemas redundantes fazendo a mesma coisa, a resposta certa pode ser consolidar, não orquestrar. A pergunta que separa os dois cenários é simples: os sistemas envolvidos precisam continuar existindo separadamente, ou a duplicação em si é o problema?
As características que se repetem nas arquiteturas financeiras mais resilientes
Olhando pelos casos, incluindo outros documentados publicamente por Uber, DoorDash e Stripe, quatro características aparecem de forma recorrente em arquiteturas financeiras que escalam bem:
- Desacoplamento orientado a eventos. Barramentos de mensageria assíncrona separam a captura da transação do processamento contábil, permitindo que um lado evolua sem travar o outro.
- Orquestração declarativa. Regras de negócio e comportamento de fluxo definidos em configuração central, não espalhados em código específico para cada novo caso. O que foi exatamente o que acelerou o Airbnb.
- Resiliência autorrecuperável. Mecanismos como chave de idempotência (evitar processar a mesma operação duas vezes) e rotinas automáticas de conciliação, para que uma falha pontual não exija intervenção manual.
- Observabilidade centrada em dado transacional. Rastrear cada valor que se move pelo sistema, não só monitorar se o servidor está de pé, é o que permite identificar a causa raiz de um incidente antes que ele afete o cliente.
O que isso muda para quem está começando esse trabalho agora
Nenhuma dessas organizações resolveu isso da noite para o dia, e nenhuma substituiu tudo de uma vez. O padrão comum, inclusive no caso de contraponto da Natura, é tratar a arquitetura de integração como uma capacidade contínua da empresa, não como um projeto que termina. É exatamente esse o princípio por trás de como a Fluid pensa orquestração para ambientes corporativos com legado. Uma camada que se posiciona na frente do sistema antigo sem exigir que ele seja substituído de uma vez. Assim a modernização acontece em fatias administráveis, não em um projeto de risco único.
Conclusão
O fio comum entre Itaú, iFood, Airbnb e a própria Natura não é o setor. É a decisão de tratar integração como capacidade permanente, não como projeto pontual. Quer discutir como isso se aplica à modernização específica do seu ambiente? Converse com o time da Fluid sobre o cenário da sua empresa.
Fontes
- Itaú Unibanco, modernização do core de contas correntes internacionais — AWS Blog Brasil
- Itaú Unibanco, modernização da plataforma de extratos — IT Forum
- iFood, decomposição do middleware financeiro em microsserviços — AWS Blog Brasil
- iFood, automação fiscal e contas a pagar via integração com Qive — Qive
- Airbnb, orquestração declarativa de métodos de pagamento locais — Airbnb Tech Blog
- Natura &Co, consolidação de 8 ERPs em uma plataforma única — Convergência Digital
- Uber, processamento de livro-razão financeiro em lote — Uber Engineering Blog
