Cada arquitetura reflete uma soma de escolhas feitas em prol de uma estratégia que deveria ser, antes de tudo, a estratégia de negócio.

Um monólito, por exemplo, prioriza controle e previsibilidade em troca de flexibilidade e escala. Já uma arquitetura distribuída faz o caminho inverso, entregando disponibilidade e resiliência, mas cobrando o preço da consistência imediata e da complexidade elevada.

Nenhuma arquitetura é neutra, cada decisão de fragmentar dados, replicar serviços, distribuir regiões ou adotar filas assíncronas carrega benefícios evidentes e riscos implícitos. O papel do CTO é equilibrar essas forças, entender não apenas o que o sistema precisa entregar, mas também o que o negócio pode suportar.

O Teorema CAP existe justamente para lembrar disso. Ele não é um limite teórico, é um mapa de compromissos. Cada ponto de escolha define o quanto de controle estamos dispostos a abrir mão em troca de disponibilidade e tolerância a falhas.

E no mercado financeiro, onde integridade e confiança valem mais que tempo de resposta, o custo dessas escolhas precisa estar explícito desde o design da arquitetura.

O Teorema CAP como mapa de decisões

O CAP afirma que, em um sistema distribuído, é impossível garantir simultaneamente consistência, disponibilidade e tolerância ao particionamento do sistema.

Em algum momento, os componentes vão deixar de se comunicar como esperado, seja por latência entre regiões, sobrecarga de filas, timeout entre serviços ou degradação localizada.

Quando isso acontece, o sistema precisa decidir entre preservar a verdade ou manter a operação.

Essa escolha é a base do CAP e o dilema de qualquer arquitetura moderna.

No contexto financeiro, esse equilíbrio é ainda mais sensível.

Cada segundo de indisponibilidade pode custar dinheiro, mas cada divergência de estado pode custar credibilidade.

E credibilidade, em sistemas financeiros, é o ativo mais caro que existe.

Os ganhos da arquitetura distribuída

Distribuir sistemas trouxe benefícios concretos, em especial para o sistema financeiro.

Escalabilidade elástica, resiliência geográfica e alta disponibilidade mudaram o jogo da infraestrutura.

Hoje, é possível lidar com milhões de transações simultâneas sem interromper o serviço, mesmo diante de degradação parcial ou isolamento de uma zona de disponibilidade.

É isso que permite que um usuário envie um PIX de madrugada, que uma API de pagamentos continue respondendo sob carga extrema ou que uma plataforma opere globalmente sem downtime perceptível.

Essa é a proposta da arquitetura distribuída e ela, via de regra, cumpre o que promete.

Mas toda proposta tecnológica vem com um preço, e neste caso, o preço é a (in)consistência eventual.

O custo da consistência eventual

Ao priorizar disponibilidade e tolerância a falhas, abrimos mão da consistência imediata.

O sistema continua de pé, mas a informação pode levar tempo para se alinhar entre os nós, ou entre os domínios e contextos de negócio.

Esse é o conceito de consistência eventual e ele carrega riscos importantes de serem considerados.

Em sistemas financeiros, o eventual pode representar riscos que se tornam necessários frente à disponibilidade e à tolerância a falhas.

Um saldo exibido antes da confirmação de uma transação, uma duplicidade em eventos de débito, um extrato defasado por alguns segundos… tudo isso faz parte do preço de manter o sistema sempre acessível.

Em uma conversa recente com meu sócio, ele comentou sobre uma arquitetura distribuída que havia construído, baseada na replicação de informações em múltiplas fontes de dados. Essa replicação, inevitavelmente, gerava riscos de inconsistência.

Alguns dos problemas mais comuns apareciam em situações simples, como durante um processo de emissão de cartão, por exemplo, o registro do cliente podia divergir entre serviços, impedindo o avanço da operação.

Em outro caso, no momento do cadastro de chaves, se o evento original de onboarding não fosse processado pelo sistema responsável pela gestão dessas chaves, o cliente não conseguia concluir o registro.

Nada disso é falha de engenharia. É o efeito colateral natural da escolha por disponibilidade.

Esses casos mostram que a consistência eventual não é um erro, é um risco estrutural que precisa ser reconhecido e mitigado.

Arquiteturas maduras não negam esse risco… elas o administram.

A responsabilidade técnica da escolha

A escolha por disponibilidade é inevitável, especialmente em um ambiente financeiro onde a operação é ininterrupta.

No ecossistema do PIX, por exemplo, o sistema funciona 24×7, e a disponibilidade deixa de ser apenas um atributo de qualidade para se tornar um requisito regulatório e reputacional.

Diante desse cenário, a pergunta certa não é “se o sistema será distribuído”, mas “como ele vai lidar com as inconsistências que a distribuição inevitavelmente trará”.

E é exatamente aí que começa a responsabilidade técnica da escolha.

Optar por disponibilidade é uma decisão legítima e necessária.

Mas assumir disponibilidade sem planejar como restaurar a verdade depois é um erro arquitetural que pode levar a perdas financeiras ou comprometer a percepção de confiança por parte do cliente.

A maturidade técnica se mede pela resolucionidade, capacidade do sistema de reconhecer, corrigir e provar a recuperação da consistência quando ela é comprometida.

Na prática, essa responsabilidade se traduz em quatro fundamentos:

1. Idempotência verdadeira — cada evento precisa gerar o mesmo resultado, independentemente de repetições ou ordem de processamento.

2. Logs imutáveis e rastreáveis — o estado real precisa ser reconstituível, sempre.

3. Observabilidade de consistência — monitorar coerência, não apenas uptime.

4. Reconciliação automatizada e contínua — o mecanismo que garante convergência entre sistemas de forma verificável.

Disponibilidade é sobre tempo de resposta.

Responsabilidade é sobre integridade.

Uma arquitetura distribuída madura precisa entregar as duas.

Reconciliação como mitigação do risco

A reconciliação de dados é o mecanismo que fecha o ciclo. Ela transforma a consistência eventual em consistência verificável.

No contexto financeiro, pode ser interpretada como reconciliação transacional. Um processo que conecta múltiplas fontes de dados com o objetivo de reconstruir a trilha executada de ponta a ponta de uma movimentação financeira.

Em vez de depender apenas da ordem dos eventos, a reconciliação atua pós-processamento, cruzando informações entre domínios, identificando divergências e ajustando o estado com segurança.

Ela é uma arquitetura de integridade, que influencia diretamente o contábil, o regulatório e a prevenção à fraude.

Funciona como uma malha de verificação contínua que mantém o sistema honesto sobre o próprio estado.

Cada ciclo de reconciliação é uma prova de integridade e, em sistemas financeiros, essa prova é o que sustenta confiança técnica, regulatória e operacional.

Escolher é inevitável, reconciliar é crucial.

Toda arquitetura é uma soma de escolhas, e toda escolha tem um preço.

O Teorema CAP apenas nos lembra disso.

Disponibilidade e tolerância a falhas são indispensáveis para escalar.

Mas ignorar o custo da consistência eventual é o que transforma eficiência em vulnerabilidade.

A maturidade técnica está em assumir o risco e projetar o controle.

A reconciliação é esse controle.

No fim, a escolha certa não é a que evita falhas, mas a que sabe restaurar a verdade quando elas acontecem.