L'ingénierie, au grand jour
Nous avons prouvé que notre grand livre reste exact à 1 600 paiements par seconde.
Un grand livre n'a pas le droit à l'erreur : les comptes doivent toujours s'équilibrer, quel que soit le volume d'argent en mouvement. Nous avons testé la vitesse et l'exactitude, puis publié chaque chiffre.
0
violation d'exactitude
Sur 1 550 594 transactions auditées.
1 600paiements/s
livrés de bout en bout
100 % d'achèvement jusqu'au sommet de la montée mesurée.
~26% utilisés
processeur d'écriture
Au débit de paiement publié le plus élevé.
L'exactitude était le critère, pas une note de bas de page
La performance ne compte qu'après l'exactitude. Nous avons traité chaque invariant du grand livre comme un critère à tolérance zéro, puis vérifié le résultat sans faire confiance à la comptabilité interne de l'application.
Après le test, un audit indépendant a recalculé chaque solde directement depuis les transactions brutes. Quatre contrôles devaient retourner exactement zéro :
Conservation
La somme signée de toutes les écritures, par devise, est nulle. L'argent n'est ni créé ni détruit.
Chaque transaction s'équilibre
Aucune transaction individuelle ne laisse les comptes déséquilibrés.
Stocké égale recalculé
Chaque solde enregistré correspond à la somme de son propre historique.
Aucun découvert sous le plancher
Aucun compte ne détient un solde interdit par ses règles.
En parallèle, le générateur de charge a surveillé les mêmes invariants et relevé 0 violation et 0 double dépense sur 623 564 opérations monétaires. Deux méthodes sans code commun, une même réponse.
Un grand livre rapide qui ne peut pas prouver qu'il est resté équilibré n'est pas rapide. C'est un risque non mesuré.
Le nœud d'écriture avait de la marge
Nous avons augmenté la charge de 400 à 1 600 paiements complets d'autorisation et de capture par seconde. Au débit maximal, l'unique nœud d'écriture utilisait environ 32 % de sa capacité d'évolution et 26 % de son processeur.
Ces chiffres partagent le même axe ci-dessous. L'espace vide au-dessus des courbes est la partie utile : une marge mesurée, pas une extrapolation.
Marge de ressources
Le nœud d'écriture est resté loin de sa limite.
Livraison de bout en bout
Chaque paiement proposé a abouti.
100 % à chaque palier
La série source est publiée dans resource-usage.csv. Les chiffres de livraison proviennent de throughput-ladder.csv.
Nous avons trouvé un mur, puis nous l'avons déplacé
Un test antérieur avait plafonné bien plus bas alors que le processeur de la base restait presque inactif. Une ressource à moitié endormie alors que le débit n'augmente plus n'est pas à sa limite : quelque chose sérialise le travail.
Nous avons remonté ce comportement jusqu'à un verrouillage dans le chemin d'écriture, l'avons supprimé et relancé le même test. Le débit a plus que triplé sans déplacer le seuil d'exactitude.
Nous ne publions pas l'implémentation de la correction. Nous publions l'habitude d'ingénierie : chercher le vrai chiffre plutôt que le chiffre flatteur, et imposer au grand livre la même tolérance zéro sous charge qu'au repos.
Les preuves sont publiques
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.