Carteira digital (com paralelo com o Pix)

01 · CONTEXTO

Do saldo agregado ao razão

No relato do Square, disparar uma liquidação bancária exigia calcular o saldo do comerciante, o que significava uma agregação group-by cara por comerciante. Além disso, por ser apenas um banco SQL, nada impedia que os pagamentos ficassem inconsistentes.

O Stripe, por sua vez, construiu o Ledger, um log imutável e auditável, como sistema de registro de seus dados financeiros.

02 · PARTIDAS DOBRADAS

Lançamentos que fecham em zero

A contabilidade de partidas dobradas obriga a declarar não só qual mudança de estado financeiro ocorreu, mas também por quê. Pela equação contábil usada pelo Square, cada transação, chamada de lançamento (journal entry), precisa fechar em zero: cada centavo perdido é compensado por um centavo ganho.

O requisito declarado é de consistência: não deve ser possível transacionar com o banco de um modo que resulte numa transação financeira ilógica.

Cada livro guarda um saldo que resume as mudanças daquele livro. No exemplo do Square, o cálculo de quanto pagar a um comerciante é uma única linha no banco e dispensa agrupamento ou agregação complexos.

1. O diagrama começa no aplicativo da carteira, ligado ao serviço de carteira.

2. O diagrama destaca o serviço e o armazenamento de lançamentos: cada lançamento declara o que mudou e por quê, e uma linha é adicionada cada vez que os livros mudam de valor.

3. Os lançamentos e as entradas de débito e crédito só recebem inserções.

4. O livro guarda um saldo que resume as mudanças dele, e esse saldo atual é atualizado a cada operação.

03 · IMUTABILIDADE

Corrigir sem apagar

No Square, os conjuntos de lançamentos e de entradas de livro são efetivamente append-only e imutáveis depois de gravados.

No Stripe, o Ledger é, no núcleo, um log imutável de eventos. Transações já publicadas não podem ser apagadas nem modificadas, e o estado passado pode ser reconstruído processando os eventos até aquele ponto.

Diante de um erro, o Square não atualiza o dado: grava um novo lançamento que corrige o anterior. O saldo do livro é ajustado, mas sempre resta um rastro do que aconteceu no sistema.

04 · CONCILIAÇÃO

Verificar que os saldos fecham

O Stripe representa os sistemas produtores como máquinas de estado e descreve o comportamento deles como um fluxo lógico de fundos, o movimento de saldos (eventos) entre contas (estados). O Ledger se baseia em partidas dobradas, método padrão para garantir que todo o dinheiro de um sistema está contabilizado ao equilibrar créditos e débitos.

1. O diagrama mostra um serviço produtor com seu banco e o ledger de eventos.

2. Os sistemas produtores são modelados como máquinas de estado, e o Ledger descreve o comportamento deles como fluxo de fundos.

3. A métrica de clearing mede a fração do ledger que está zerada como deveria em regime estável.

4. A verificação de completude garante que todo ID no banco do produtor tem um evento correspondente no ledger.

5. Na pontualidade, mede-se a diferença entre a entrada do dado na plataforma e a chegada ao ledger.

6. O Ledger depende de alertas proativos para trazer à tona problemas e soluções propostas.

Se o evento de liberação nunca é publicado ou tem id errado, o Ledger não compensa o saldo da conta associada. Mesmo com bilhões de transações, uma única transação ausente, atrasada ou incorreta cria de imediato um problema de exatidão detectável por uma consulta simples.

05 · ESCALA E ENTREVISTA

Armazenamento e escala do razão

O Square relata esforço considerável num esquema de sharding do banco SQL e conta que precisou lidar com transações entre shards, em que dois comerciantes podiam trocar valor.

Para o Books, o Square escolheu o Google Cloud Spanner, um banco SQL totalmente gerenciado e distribuído globalmente, que o dispensou de se preocupar com sharding e com o ônus de manter um banco.