L'ingénierie, au grand jour
Comment nous testons un grand livre, et ce qu'un paiement par seconde signifie vraiment
Un chiffre de benchmark ne vaut que par sa définition. Voici comment nous chargeons le grand livre, ce que compte une transaction par seconde et pourquoi la méthode reflète un trafic réel.
Nous avons publié trois résultats : le grand livre reste exact à grande échelle, il échoue proprement sous surcharge, et sa limite restante est du calcul ordinaire, pas le grand livre. Chacun cite un débit en paiements par seconde.
Ce débit ne vaut que par sa définition. « 10 000 requêtes par seconde » peut désigner des lectures bon marché, des échecs ou un pic de deux secondes. Voici donc exactement ce que nous comptons, comment nous produisons la charge et pourquoi cette méthode reflète la production.
1transaction
= autorisation + capture
Deux appels API qui valident une transaction équilibrée. Ni requête brute, ni lecture.
100%
de livraison, sinon nous ne l'affirmons pas
Nous citons le débit maximal où chaque paiement proposé aboutit dans le budget.
0
tolérance pour des comptes faux
Après chaque test, l'exactitude est auditée depuis les données brutes.
Ce que compte réellement une transaction par seconde
Un paiement est un cycle complet d'autorisation et de capture : une requête réserve les fonds, une seconde les capture. Ce cycle valide une transaction du grand livre et des écritures en partie double équilibrées.
- Ce n'est pas une requête HTTP brute. Chaque transaction comptée contient deux requêtes séquentielles.
- Ce n'est pas une lecture. Chaque transaction déplace de l'argent et écrit durablement.
- C'est le chemin lourd. Autoriser puis capturer demande plus de travail qu'un paiement en une étape.
Nous comptons les transactions terminées, pas la charge proposée. Le bon débit, pas les tentatives.
Comment nous produisons la charge
Nous appliquons une échelle de paliers : un taux d'arrivée fixe est maintenu, puis augmenté. Chaque palier est lu séparément, ce qui laisse les percentiles de latence se stabiliser.
Le générateur n'est jamais le goulot. Il fonctionne dans le même réseau, avec assez de workers et de connexions. S'il ne peut pas offrir la charge, nous marquons le palier comme limite client et ne le présentons pas comme capacité.
Chaque test démarre propre et chaud. Le grand livre est réinitialisé et une phase d'échauffement précède les mesures.
Le trafic est réparti comme en production. Il touche de nombreux comptes et marchands, pas une seule ligne chaude.
L'exactitude est mesurée deux fois. Le générateur surveille les invariants en direct, puis un audit séparé recalcule les soldes depuis les données brutes.
Les échecs sont classés. Un signal réessayable protège le système ; une réponse 5xx ou un délai dépassé est un véritable échec. Nous ne les mélangeons pas.
Conservation
La somme signée des écritures est nulle par devise.
Chaque transaction s'équilibre
Aucune transaction ne laisse les comptes déséquilibrés.
Stocké égale recalculé
Chaque solde correspond à son historique.
Aucun découvert interdit
Aucun compte ne franchit ses règles configurées.
Ce que « livré » signifie précisément
Nous publions le palier le plus élevé où tous les paiements proposés aboutissent dans un budget de latence acceptable, sans échec réel ni violation du grand livre.
- Le système refuse rapidement l'excès avec un signal réessayable. La livraison baisse, mais rien ne casse ni ne se perd.
- Le système se dégrade en validant encore le travail, mais avec une latence supérieure au budget.
Nous n'appelons jamais capacité un palier que le client n'a pas pu produire.
Pourquoi la méthode reflète la production
- Les chemins monétaires sont réels. Autorisation, capture et écritures équilibrées utilisent le code destiné à déplacer l'argent.
- Le cas de concurrence le plus difficile est imposé. Les comptes dépensent contre une limite réelle.
- L'exactitude reste à zéro et est prouvée séparément.
- Le résultat est un point d'exploitation avec de la marge, pas une falaise.
- Il est reproductible. Les données brutes et leur manifeste sont publics.
Un benchmark impossible à reproduire est une affirmation marketing. Avec les données brutes et le comportement d'échec ouverts, il devient une preuve.
Les limites, honnêtement
- Il s'agit d'un benchmark synthétique sur une infrastructure de préproduction, pas de trafic de production.
- Un débit mesuré est le sommet de ce que nous avons produit, pas un plafond absolu.
- Une réponse occupé réessayable n'est pas une erreur serveur.
Accès anticipé
Devenez partenaire de conception.
Nous travaillons avec un petit nombre d'équipes qui construisent des produits de portefeuille et de paiement sur WalletD. Si c'est votre cas, parlons-en. Vous aurez un accès direct aux personnes qui l'ont conçu.