Banco por Dentro (3/3): A Arquitetura de Sistemas de um Banco

Imagine o Git: você nunca apaga um commit, só adiciona novos. O histórico é imutável e auditável. O ledger bancário funciona exatamente assim — e por razões que vão muito além da preferência técnica.

A contabilidade de dupla entrada diz que toda movimentação de dinheiro tem dois lados: um débito e um crédito. Quando você transfere R$ 100 da sua conta para a de outra pessoa, o sistema registra: débito na sua conta (saldo diminui) e crédito na conta do destinatário (saldo aumenta). A soma algébrica é sempre zero. Isso não é uma regra do banco — é um princípio contábil de 500 anos que garante que dinheiro não some nem apareça do nada.

Do ponto de vista de engenharia, isso mapeia diretamente para Event Sourcing (Martin Fowler): o estado atual (saldo) não é armazenado diretamente — ele é derivado da sequência de eventos imutáveis (lançamentos). Você pode recalcular o saldo de qualquer conta em qualquer ponto no tempo simplesmente replaying os eventos até aquela data. Isso tem consequências profundas: auditoria é trivial, rollback é um estorno (novo evento, não deleção), e inconsistências ficam visíveis porque a soma dos lados nunca fecha.

Para um dev vindo de CRUD: esqueça o UPDATE saldo = saldo - 100. No ledger você faz INSERT INTO lancamentos (conta, tipo, valor, idempotency_key, timestamp). O saldo é uma view, não uma coluna.

Um banco não é um monolito com uma tabela de saldo. É um conjunto de motores especializados, cada um com responsabilidade clara e fronteiras bem definidas — o que um arquiteto de software reconheceria como Domain-Driven Design aplicado a décadas de regulação.

Motor de Contas: mantém o cadastro de clientes e contas. Não mexe em saldo. Pensa nele como o serviço de users + accounts do seu sistema, mas com obrigação legal de KYC (Know Your Customer — verificação de identidade exigida pelo BACEN).

Motor de Limites: antes de qualquer transação ser processada, o limite é consultado e reservado. Funciona como um semáforo: se não há limite disponível, a transação nem chega ao ledger. Isso evita race conditions de saldo negativo sem precisar de lock na tabela principal.

Motor de Crédito: avalia score, concede crédito e, quando aprovado, instrui o ledger a fazer o desembolso. É o único motor que pode criar dinheiro na conta do cliente sem que ele tenha depositado antes — daí a importância da sua auditabilidade.

Boletador: gera o boleto, calcula o código de barras, registra na CIP (Câmara Interbancária de Pagamentos) e monitora o pagamento. Quando o boleto é pago em outro banco, a CIP notifica o boletador, que instrui o ledger.

Motor de Liquidação: traduz a intenção interna ('transferir R$ 100 para fulano') em mensagens para o BACEN (STR para TED, SPI para PIX). É a ponte entre o mundo interno do banco e o sistema financeiro nacional.

Em qualquer sistema distribuído, falhas parciais acontecem: a rede cai depois que você enviou a requisição mas antes de receber a resposta. No seu serviço de e-mail, isso significa reenviar o e-mail — chato, mas inofensivo. Em dinheiro, significa debitar duas vezes.

Idempotência é a propriedade que garante: não importa quantas vezes você processe a mesma operação, o efeito é o mesmo que processar uma vez. A implementação canônica é simples: cada transação carrega um idempotency_key único (gerado pelo cliente, geralmente um UUID). Antes de processar, o ledger verifica: 'já vi essa chave?' Se sim, retorna o resultado anterior sem reprocessar. Se não, processa e persiste a chave junto com o resultado.

Isso parece trivial até você pensar em filas de eventos. Quando você usa Kafka (ou AWS MSK), a semântica padrão é at-least-once delivery: a mensagem pode ser entregue mais de uma vez, especialmente em reprocessamento após falha. Se o seu consumer não for idempotente, você tem um bug que só aparece sob pressão — exatamente o cenário do incidente Coinbase/AWS MSK de 2021, onde uma partição Kafka ficou indisponível e o reprocessamento causou inconsistências contábeis.

A regra de ouro: nunca confie que uma mensagem chegou exatamente uma vez. Projete todos os consumers financeiros como idempotentes. O idempotency_key deve ser persistido no mesmo banco, na mesma transação ACID que o lançamento contábil — não em cache separado.

Em sistemas bancários, a tríade clássica de engenharia — disponibilidade, consistência, tolerância a partição (CAP) — tem um peso diferente. Um banco prefere ficar indisponível a ficar inconsistente. Isso não é dogma: é regulação. O BACEN pode multar um banco por saldo incorreto muito mais severamente do que por uma janela de manutenção.

O incidente da Coinbase com AWS MSK (2021) é um caso didático: uma partição Kafka ficou indisponível, o sistema fez reprocessamento automático dos eventos, e consumers não-idempotentes geraram lançamentos duplicados. O problema não foi o Kafka — foi a ausência de idempotência nos consumers. A lição: infraestrutura resiliente não substitui design idempotente.

Para segurança, o conceito central é o HSM (Hardware Security Module). Pense nele como um cofre físico que faz cálculos criptográficos internamente: você envia os dados, ele retorna o resultado assinado, mas as chaves privadas nunca saem do hardware. Isso é exigido pelo PCI-DSS para operações com cartão e pelo BACEN para assinatura de mensagens no SPB. AWS CloudHSM e Azure Dedicated HSM são opções de nuvem que mantêm essa garantia.

Auditabilidade é a outra face da moeda: todo lançamento, toda decisão de crédito, toda alteração de limite deve ser registrada em um audit log imutável (WORM — Write Once Read Many). Na AWS, S3 Object Lock com Compliance Mode implementa isso. O BACEN exige retenção mínima de 5 anos para a maioria dos registros transacionais.

Gregor Hohpe descreve o arquiteto como alguém que transita entre o andar executivo (estratégia, regulação, produto) e o andar técnico (código, infraestrutura, operações) — o 'Architecture Elevator'. Esta série inteira foi essa viagem.

A Parte 1 subiu ao andar executivo: o que é um banco, como o BACEN regula, o que é o SPB. A Parte 2 parou no andar de produto: os rails de pagamento, como PIX, TED e boleto funcionam do ponto de vista do usuário e do negócio. Esta Parte 3 desceu até o subsolo técnico: o ledger, os motores, idempotência, HSM.

O insight que conecta os três andares: cada decisão de negócio tem um custo técnico, e cada escolha técnica tem uma consequência de negócio. O BACEN exige auditabilidade por 5 anos (negócio) → você precisa de WORM storage (técnico). PIX é liquidação em tempo real (negócio) → você precisa de consumers idempotentes e conciliação automática (técnico). Crédito é criação de dinheiro (negócio) → o motor de crédito precisa de consistência forte e trilha de auditoria (técnico).

Para um dev ou arquiteto entrando nesse domínio: o maior erro é tratar o sistema bancário como 'só mais um microsserviço com dinheiro'. As restrições são diferentes, as consequências de falha são diferentes, e o modelo mental precisa mudar antes do código.