Engenharia, às claras

Como testamos um ledger e o que um pagamento por segundo realmente significa

Um número de benchmark só é tão bom quanto sua definição. Veja como geramos carga, o que conta uma transação por segundo e por que o método representa tráfego real.

Diagrama definindo uma transação como ciclo completo de autorização e captura que confirma uma transação equilibrada em partidas dobradas, acima de patamares de carga de 400 a 2.600 pagamentos por segundo.

Publicamos três resultados: o ledger permanece correto em escala, falha com segurança sob sobrecarga e seu limite restante é computação comum, não o ledger. Todos citam pagamentos por segundo.

Essa taxa só é confiável quando definida. “10 mil requisições por segundo” pode significar leituras baratas, metade de falhas ou um pico de dois segundos. Por isso explicamos exatamente o que contamos e como dirigimos a carga.

1transação

= autorizar + capturar

Duas chamadas API que confirmam uma transação equilibrada. Não uma requisição bruta nem leitura.

100%

de entrega, ou não afirmamos

Citamos a maior taxa em que todos os pagamentos concluem dentro do orçamento.

0

tolerância para livros errados

A correção é auditada dos registros brutos após cada teste.

O que uma transação por segundo realmente conta

Um pagamento é um ciclo completo de autorização e captura: uma requisição reserva fundos e outra os captura. O ciclo confirma uma transação do ledger com lançamentos equilibrados.

  • Não é uma requisição HTTP bruta. Cada transação contada envolve duas requisições sequenciais.
  • Não é uma leitura. Cada transação movimenta dinheiro e grava no ledger durável.
  • É o caminho pesado. Autorizar e capturar faz mais trabalho do que um pagamento em etapa única.

Contamos transações concluídas, não carga oferecida. Vazão útil, não tentativas.

Como dirigimos a carga

Usamos uma escada de patamares: mantemos uma taxa fixa, subimos um degrau e medimos cada patamar separadamente para a latência se estabilizar.

O gerador nunca é o gargalo. Ele roda na mesma rede, com workers e conexões suficientes. Se não consegue oferecer a carga, marcamos limite do cliente e não publicamos como capacidade.

Cada execução começa limpa e aquecida. O ledger é reiniciado e uma etapa de aquecimento precede a medição.

O tráfego se espalha como tráfego real. A carga atinge muitas contas e lojistas, não uma linha quente.

A correção é medida de duas formas. O gerador acompanha invariantes ao vivo e uma auditoria separada recalcula os saldos dos dados brutos.

Falhas são classificadas. Um sinal ocupado e repetível protege o sistema; 5xx ou timeout é falha real. Não misturamos os dois.

Conservação

A soma assinada fecha em zero por moeda.

0

Toda transação fecha

Nenhuma transação deixa os livros desequilibrados.

0

Armazenado igual a recalculado

Cada saldo corresponde ao histórico.

0

Nenhum saldo proibido

Nenhuma conta viola suas regras.

0

O que “entregue” significa, exatamente

Relatamos o maior patamar em que todos os pagamentos oferecidos concluíram dentro do orçamento de latência, com zero falhas reais e zero violações.

  • O sistema recusa rapidamente o excesso com um sinal repetível. A entrega cai, mas nada quebra nem se perde.
  • O sistema degrada, ainda confirmando o trabalho, mas acima do orçamento de latência.

Nunca chamamos de capacidade um patamar que o cliente não conseguiu oferecer.

Por que o método representa produção

  • Os caminhos de dinheiro são reais. Autorização, captura e lançamentos usam o código que moveria dinheiro do cliente.
  • O caso de concorrência mais difícil é aplicado. Contas gastam contra um limite real.
  • A correção é zero e provada de forma independente.
  • O resultado é um ponto operacional com folga, não um precipício.
  • É reproduzível. Dados brutos e manifesto são públicos.

Um benchmark que você não consegue reproduzir é uma afirmação de marketing. Com dados brutos e comportamento de falha abertos, ele vira evidência.

Os limites honestos

  • É um benchmark sintético em staging, não tráfego de produção.
  • A taxa medida é o topo do que dirigimos, não um teto absoluto.
  • Uma resposta ocupado repetível não é falha de servidor.

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.