Engenharia, às claras
Provamos que nosso ledger permanece correto a 1.600 pagamentos por segundo.
Um ledger tem uma obrigação que nunca pode falhar: os livros precisam fechar, sempre, independentemente de quanto dinheiro esteja em movimento. Testamos velocidade e correção e publicamos todos os números.
0
violações de correção
Em 1.550.594 transações auditadas.
1.600pagamentos/s
entregues de ponta a ponta
100% de conclusão até o topo da rampa medida.
~26% usado
processador do writer
Na maior taxa de pagamento publicada.
Correção foi o critério, não uma nota de rodapé
Desempenho só importa depois da correção. Tratamos cada invariante como um critério de tolerância zero e verificamos o resultado sem confiar na contabilidade do próprio aplicativo.
Depois do teste, uma auditoria independente recalculou cada saldo diretamente dos registros brutos. Quatro verificações precisavam retornar exatamente zero:
Conservação
A soma assinada de todos os lançamentos, por moeda, é zero. O dinheiro não é criado nem destruído.
Toda transação fecha
Nenhuma transação individual deixa os livros desequilibrados.
Armazenado igual a recalculado
Cada saldo armazenado corresponde à soma do próprio histórico.
Nenhum saldo abaixo do piso
Nenhuma conta mantém um saldo proibido por suas regras.
Em paralelo, o gerador acompanhou os mesmos invariantes e registrou 0 violações e 0 gastos duplos em 623.564 operações. Dois métodos, sem código compartilhado, mesma resposta.
Um ledger rápido que não consegue provar que permaneceu equilibrado não é rápido. É um risco não medido.
O writer tinha folga
Elevamos a carga de 400 para 1.600 pagamentos completos de autorização e captura por segundo. No topo, um único writer usou cerca de 32% da capacidade de escala e 26% do processador.
Os números compartilham um eixo abaixo. O espaço vazio acima das linhas é a parte útil: folga medida, não uma extrapolação.
Folga de recursos
O writer ficou bem abaixo do limite.
Entrega de ponta a ponta
Todos os pagamentos oferecidos foram concluídos.
100% em todos os patamares
A série de origem está em resource-usage.csv. Os dados de entrega vêm de throughput-ladder.csv.
Encontramos um muro e o movemos
Um teste anterior atingiu um teto bem mais baixo enquanto o processador do banco permanecia quase ocioso. Um recurso meio adormecido enquanto a vazão para de crescer não está no limite; algo está serializando o trabalho.
Rastreamos o comportamento até um gargalo de locking no caminho de escrita, removemos o ponto e repetimos o mesmo teste. A vazão mais que triplicou sem mudar o critério de correção.
Não publicamos a implementação da correção. Publicamos o hábito de engenharia: buscar o número verdadeiro, não o mais bonito, e manter a mesma tolerância zero sob carga e em repouso.
As evidências são públicas
Acesso antecipado
Torne-se um parceiro de design.
Estamos trabalhando com um pequeno numero de equipes que constroem produtos de carteira e financeiros sobre o WalletD. Se essa e a sua equipe, vamos conversar. Voce tera acesso direto as pessoas que o construiram.