Migração de Arquitetura de Monólitos Distribuídos para Core Bancário Baseado em Eventos

O Calcanhar de Aquiles dos Monólitos Distribuídos no Setor Financeiro

Muitas instituições financeiras nasceram digitais sob a promessa de agilidade, adotando arquiteturas que pareciam modernas na época, mas que hoje revelam um grave problema conhecido como monólito distribuído. Na prática, isso significa que, embora os sistemas rodem em servidores separados, eles dependem tanto uns dos outros através de chamadas síncronas que funcionam como uma grande gelatina: se você mexe em um ponto, tudo o resto balança junto. Quando um cliente tenta fazer um Pix, por exemplo, o sistema de contas precisa consultar o limite de crédito, verificar o cadastro, registrar a auditoria e emitir notificação em milissegundos. Se a API de crédito cair, a transação inteira falha, gerando frustração no usuário e chamados urgentes para a equipe de tecnologia.

Esse acoplamento temporal excessivo destrói a resiliência operacional que o negócio tanto precisa para crescer de forma sustentável. A manutenção de contratos rígidos de API REST bloqueia entregas contínuas, pois qualquer alteração em um campo obriga dezenas de equipes a atualizarem seus códigos simultaneamente sob risco de quebrar a produção. Para romper esse ciclo vicioso, a engenharia de software moderna recorre a uma mudança profunda de paradigma: sair da comunicação direta e imperativa para a arquitetura orientada a eventos, onde os sistemas apenas anunciam fatos que ocorreram e deixam que outros interessados reagiam a eles no seu próprio ritmo.

Mapeando Fronteiras de Domínio com Event Storming

O primeiro passo prático na jornada de migração de um core bancário legado não começa escrevendo código, mas entendendo a linguagem ubíqua do negócio através de uma técnica colaborativa chamada event storming. Na prática, essa abordagem reúne desenvolvedores, analistas de negócios e especialistas de domínio em uma sala para mapear todos os eventos significativos que acontecem na instituição financeira em ordem cronológica. Termos como ContaAberta, SaldoAtualizado ou PixEfetuado ganham protagonismo absoluto, pois representam fatos consumados no passado que não podem ser desfeitos, apenas compensados se necessário.

Ao isolar esses eventos, a equipe consegue desenhar os limites contextuais exatos que separarão os domínios de negócio, como pagamentos, cartões, empréstimos e compliance. Cada contexto assume a responsabilidade exclusiva por seus dados, eliminando a prática desastrosa de consultas diretas a bancos de dados alheios em tempo de execução. Se o sistema de cartões precisa saber se a conta tem saldo para aprovar uma compra, ele não acessa mais a tabela de contas diretamente; ele consome um fluxo contínuo de eventos de alteração de saldo gerado pela conta, mantendo uma cópia local atualizada de forma assíncrona para consulta rápida.

Superando o Dilema da Escrita Dupla com o Transactional Outbox

Um dos maiores pesadelos técnicos na construção de sistemas baseados em eventos é o problema da escrita dupla, que ocorre quando uma aplicação precisa salvar dados em seu banco de dados relacional e, logo em seguida, publicar um evento em uma fila de mensagens como o Apache Kafka. Na prática, se o banco salvar os dados mas a conexão com a fila cair antes da publicação, o restante do sistema nunca saberá que o evento aconteceu, gerando dessincronização crônica de saldos. Tentar resolver isso com código de tratamento de erro comum gera falhas silenciosas difíceis de depurar em ambientes de alta volumetria financeira.

A solução definitiva para esse impasse de engenharia é a adoção do padrão arquitetural Transactional Outbox, que garante atomicidade entre a persistência e a mensageria. Em vez de enviar a mensagem diretamente para a rede, a aplicação grava o registro de negócio e o evento pendente dentro da mesma transação de banco de dados, em uma tabela dedicada chamada outbox. Um processo secundário ou um conector de captura de dados modificados lê essa tabela sequencialmente e despacha os eventos para a fila com garantia de entrega at-least-once, assegurando que nenhum dado financeiro se perca pelo caminho.

-- Exemplo de tabela Outbox para garantir atomicidade transacional no core bancario
CREATE TABLE transaction_outbox (
    id UUID PRIMARY KEY,
    aggregate_id VARCHAR(255) NOT NULL,
    event_type VARCHAR(100) NOT NULL,
    payload JSONB NOT NULL,
    created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP,
    status VARCHAR(20) DEFAULT 'PENDING'
);

-- Insercao atomica junto com a atualizacao da conta
BEGIN;
UPDATE accounts SET balance = balance - 150.00 WHERE id = 'acc-123';
INSERT INTO transaction_outbox (id, aggregate_id, event_type, payload)
VALUES ('uuid-gen', 'acc-123', 'AccountDebited', '{"amount": 150.00, "currency": "BRL"}');
COMMIT;

Garantindo Consistência e Ordenação em Transações Distribuídas

Sistemas financeiros exigem precisão absoluta na ordem cronológica dos eventos para evitar que um extrato mostre o débito acontecendo antes do depósito correspondente. Em barramentos de mensagens distribuídos, isso significa que a chave de particionamento deve ser escolhida com extremo rigor técnico para agrupar mensagens correlacionadas na mesma partição física. Na prática, se utilizarmos o número da conta corrente como chave de particionamento no Kafka, todos os eventos referentes àquela conta específica serão processados estritamente na mesma ordem em que foram gerados, eliminando condições de corrida críticas.

Quando transações envolvem múltiplos microsserviços que não podem ser resolvidos por uma simples transação de banco, a arquitetura adota o padrão Saga, que substitui o bloqueio global por uma sequência de transações locais coordenadas por eventos. Se uma das etapas falhar por falta de limite ou fraude, a Saga executa transações compensatórias automáticas para desfazer os passos anteriores de forma controlada. Embora isso introduza a chamada consistência eventual, onde o saldo pode levar alguns milissegundos para refletir o estado final, o ganho em escalabilidade e disponibilidade compensa amplamente essa transição conceitual.

Considerações Finais sobre a Evolução Arquitetural

A transição de um monólito distribuído para um core bancário baseado em eventos não é apenas uma mudança de ferramentas ou migração para a nuvem, mas uma evolução cultural profunda na forma como a engenharia lida com o tempo e o estado dos dados. Substituir chamadas síncronas frágeis por fluxos assíncronos desacoplados exige rigor na modelagem de domínios, disciplina no versionamento de contratos de mensagens e robustez nas ferramentas de observabilidade e rastreamento distribuído. Com essas fundações sólidas, as instituições ganham a elasticidade necessária para absorver picos massivos de acesso, como a Black Friday ou dias de pagamento, sem comprometer a estabilidade operacional.

Em última análise, o sucesso dessa jornada de modernização arquitetural reside na paciência estratégica e na entrega incremental, mitigando riscos através de strangler figs e testes rigorosos de caos. Ao tratar eventos como cidadãos de primeira classe na arquitetura financeira, a tecnologia deixa de ser um gargalo operacional e passa a atuar como o verdadeiro motor de inovação e confiança para milhões de clientes no dia a dia.