TigerBeetle est la base de données la plus intéressante au monde
(amplifypartners.com)- TigerBeetle, une base de données de transactions financières, est une nouvelle base de données qui prend en charge nativement les débits (debit) et les crédits (credit). Là où les bases SQL traditionnelles nécessitaient 10 à 20 requêtes pour une seule transaction, elle peut traiter 8 190 transactions en un seul aller-retour
- Alors que d’innombrables systèmes privilégient la rapidité de développement et l’accumulation de dépendances, ce projet s’en tient à des stratégies à contre-courant comme écrire le code lentement, les tests de simulation déterministe (DST) et le zéro dépendance
- À la différence des bases OLTP traditionnelles reposant sur une architecture à nœud unique, elle intègre dès sa conception le distribué par défaut, la tolérance aux pannes d’horloge (cluster time) et la tolérance aux défaillances du stockage, tout en s’appuyant sur Viewstamped Replication et Zig pour gagner en simplicité d’implémentation et en visibilité
- Elle applique la méthodologie TigerStyle, inspirée du Power of Ten de la NASA, avec des standards de code stricts : en moyenne plus de 2 assertions par fonction, allocation mémoire statique imposée, assertions activées même en production
- Conçue pour l’ère de l’hyper-transactionnalité — paiements temps réel, gaming, facturation énergétique, etc. — elle pose un nouveau référentiel de performance et de justesse pour l’OLTP de nouvelle génération et s’impose comme un système transactionnel destiné à remplacer les bases SQL vieilles de 20 à 30 ans
Pourquoi une base de données centrée sur les débits/crédits est nécessaire
- TigerBeetle est une « base de données de transactions financières » qui utilise les débits (debit) et les crédits (credit) comme primitives fondamentales
- En 1985, Jim Gray définissait l’essence d’une transaction non pas comme une transaction SQL, mais comme une transaction métier (débit/crédit)
- Vingt ans plus tard, Gray définissait toujours le traitement transactionnel standard comme « DebitCredit » : débiter un compte bancaire, effectuer une écriture en partie double, puis répondre au terminal
- Les débits/crédits ne servent pas uniquement à la comptabilité ou à la banque : ils constituent un langage commun qui exprime la nature même de la transaction, ce qui explique aussi pourquoi ils offrent des garanties de type ACID
- Les limites d’une implémentation débit/crédit sur une base SQL classique
- Pour traiter une seule opération de débit/crédit, il faut 10 à 20 requêtes SQL : lecture du solde, verrouillage de ligne, attente d’une décision dans le code, enregistrement du débit/crédit, etc.
- Il faut conserver les verrous de ligne pendant les allers-retours réseau, ce qui aggrave les problèmes de hot row quand de nombreuses transactions accèdent au même « house account »
- Avec des milliards de paiements instantanés mensuels en Inde et au Brésil, FedNow aux États-Unis, et la facturation temps réel dans l’énergie, le gaming ou le cloud, le monde est devenu au moins cent fois plus transactionnel en dix ans, alors que les bases SQL utilisées aujourd’hui reposent sur des technologies vieilles de 20 à 30 ans
- Ce qui distingue TigerBeetle
- Les débits/crédits sont conçus comme des primitives de premier ordre, ce qui permet de traiter 8 190 transactions dans une seule requête de 1 MiB et en un seul aller-retour
- Son fondateur Joran qualifie cela d’« idée de performance x1000 », tout en disant que ce n’est « rien de spécial »
- Alors qu’une base de données demande généralement 10 ans de développement, TigerBeetle a été achevée en 3,5 ans et a passé les tests Jepsen
- En juin 2025, Kyle Kingsbury n’a pas réussi à briser les fondations de TigerBeetle, même en corrompant divers emplacements sur toutes les machines (il n’a trouvé qu’un seul bug de justesse dans le moteur de requêtes en lecture, sans impact sur la durabilité)
Conception moderne d’une base de données
Architecture distribuée par défaut
- À l’époque où Postgres et MySQL ont été conçus, le paradigme du nœud unique dominait, alors qu’à l’ère actuelle du matériel cloud mutualisé, le paradigme distribué est devenu la norme
- Une base de données moderne doit offrir une sérialisabilité stricte et répliquer les transactions entre machines pour assurer redondance, tolérance aux pannes et haute disponibilité
- Certaines des bases OLTP les plus populaires reposent encore largement sur une architecture à nœud unique, avec parfois l’absence de basculement automatique intégré par défaut
- L’architecture distribuée de TigerBeetle
- Elle est construite pour être distribuée par défaut : il suffit d’installer le binaire sur autant de machines que souhaité dans le cluster
- Pas besoin de réplication asynchrone, de Zookeeper, etc. ; l’équipe a investi dans une implémentation du protocole de consensus pionnier du MIT, Viewstamped Replication
- En dehors de la toolchain Zig, elle conserve zéro dépendance et investit directement dans toutes les dépendances essentielles
Tolérance aux pannes d’horloge
- En tant que base de données transactionnelle, TigerBeetle accorde de l’importance à la précision des horodatages physiques pour l’audit et la conformité
- Linux propose plusieurs horloges :
CLOCK_MONOTONIC_RAW,CLOCK_MONOTONIC,CLOCK_BOOTTIME - Les imperfections physiques des horloges matérielles font qu’elles avancent à des rythmes différents, provoquant des erreurs de drift qui s’accumulent ensuite en erreurs de skew
- En général, NTP corrige ces erreurs, mais en cas de panne réseau partielle interrompant silencieusement NTP, un cluster de consensus hautement disponible peut continuer à fonctionner dans le noir
- Linux propose plusieurs horloges :
- L’implémentation du cluster time
- En combinant la majorité des horloges du cluster, TigerBeetle construit une horloge tolérante aux pannes appelée « cluster time »
- Si nécessaire, elle réaligne l’heure système des serveurs ou s’arrête proprement si trop d’horloges sont défectueuses
- Elle détecte réellement quand Chrony, PTP ou NTP cessent de fonctionner et alerte les opérateurs
- Elle suit et échantillonne les décalages d’horloge entre serveurs, puis estime l’intervalle le plus précis via l’algorithme de Marzullo
Gestion des pannes de stockage
-
Les hypothèses des bases de données traditionnelles
- Elles supposent qu’en cas de panne disque, le système échoue de manière prévisible avec un message d’erreur
- La documentation de SQLite indique : « SQLite n’ajoute aucune redondance au fichier de base de données pour détecter une corruption ou des erreurs d’E/S, et suppose que les données lues sont exactement identiques à celles qui ont été écrites auparavant. »
-
Les scénarios réels de panne de stockage
- Un disque peut retourner silencieusement des données corrompues, acheminer des E/S dans la mauvaise direction (chemin de lecture/écriture), ou subir une gray failure en ralentissant brusquement sans code d’erreur
-
La tolérance aux pannes de stockage de TigerBeetle
- Grâce à Protocol Aware Recovery, la disponibilité est maintenue tant qu’une copie des données n’est pas corrompue sur l’ensemble des répliques
- Toutes les données sont immuables, avec des sommes de contrôle et des chaînes de hachage garantissant fortement l’absence de corruption ou de falsification
- Son propre cache de pages, l’écriture disque via O_DIRECT, et l’exécution directe sur un périphérique bloc brut (sans système de fichiers) permettent de réduire au minimum les couches entre le disque et le logiciel
- Au lieu d’un LSM standard du commerce, elle utilise une LSM Forest maison (environ 20 arbres LSM)
- Elle n’affirme pas seulement tolérer les pannes de stockage : c’est aussi la seule base de données distribuée dont cela a été vérifié par Jepsen
- En cas de panne locale, même si seuls des secteurs disque échouent, le moteur de stockage reste connecté au consensus global et peut s’auto-réparer via le cluster
Pourquoi le langage Zig
-
Les langages des bases de données existantes
- Postgres est écrit en C (années 1970), MySQL en C et C++ (1979), MSSQL aussi en C et C++
- Les langages de programmation ont énormément évolué en 40 ans, et une conception moderne pourrait choisir Rust ou Zig
-
Pourquoi TigerBeetle a choisi Zig
- Il permet de tirer parti de tout l’écosystème C et fournit une excellente toolchain et un excellent compilateur
- Il est facile à écrire et surtout facile à lire, parfois aussi simple que TypeScript tout en étant bien plus rapide
- Il permet l’allocation mémoire statique, un principe central de TigerBeetle
- Il offre une excellente expérience développeur et s’apprend vite, ce qui facilite l’entrée rapide dans le code source de TigerBeetle
- Des membres historiques de l’équipe Rust comme Matklad (créateur de Rust Analyzer) et Brian Anderson (cofondateur de Rust avec Graydon) travaillent chez TigerBeetle
- En Rust, se passer d’allocation mémoire dynamique relève du « hard mode », alors qu’en Zig c’est simple
Deterministic Simulation Testing et VOPR
Les bases du DST
-
Deterministic Simulation Testing (DST) est une technique de test innovante popularisée par l’équipe de FoundationDB (désormais propriété d’Apple)
- Elle sert à développer des bases de données distribuées plus sûres et avec moins de bugs en moins de temps qu’auparavant
- Les systèmes distribués comportent une infinité de combinaisons de problèmes de concurrence : perte de messages, ordre d’exécution imprévisible des threads, etc.
- Les tests unitaires et d’intégration traditionnels sont insuffisants, et la vérification formelle coûte cher et reste lente
-
Comment fonctionne le DST
- Il s’agit d’un simulateur qui exécute de façon déterministe presque tous les scénarios possibles auxquels le système peut être confronté sur une ligne temporelle donnée
- Il prend aussi en compte des facteurs externes comme l’OS, le réseau, les problèmes de disque ou différents types de latence
- Il permet d’obtenir en peu de temps l’équivalent de plusieurs années de tests (le temps lui-même devenant déterministe, des boucles
while truesont possibles) - Il est particulièrement adapté aux bases de données, gourmandes en E/S mais peu intensives en calcul
- Les tests Jepsen ne sont qu’un sous-ensemble de ce que le DST peut faire
Le VOPR de TigerBeetle
-
Vue d’ensemble de VOPR (Viewstamped Operation Replicator)
- Il s’agit d’un cluster de test développé en interne, dont le nom vient du simulateur WOPR du film WarGames
- Il teste en continu TigerBeetle dans d’innombrables conditions, du mode d’élection du leader par les nœuds jusqu’aux états individuels et aux pannes réseau
- Il permet de simuler virtuellement un cluster distribué complet dans un seul thread
-
L’ampleur de VOPR
- C’est le plus grand cluster DST au monde, exécuté sur 1 000 cœurs CPU
- Son échelle est si inhabituelle que Hetzner a envoyé un e-mail spécial pour vérifier que l’équipe voulait réellement autant de cœurs
- VOPR-1000 tourne 24x7x365 pour capturer autant que possible les conditions rares avant la production
- Dans le simulateur, le temps est abstrait de manière déterministe et accéléré d’environ 700x, ce qui permet d’accumuler environ 2 000 ans de temps de simulation par jour
Le DST transformé en jeu
- TigerBeetle a transformé le DST en jeu, permettant de tester divers scénarios de panne à travers la réaction du système
- Le jeu est accessible sur sim.tigerbeetle.com
- Il exécute de véritables instances de VOPR dans le navigateur pour simuler TigerBeetle
- Il a été compilé en WebAssembly, et les ingénieurs de TigerBeetle ont créé l’interface du jeu pour visualiser le système réel
TigerStyle et Power of Ten
La méthodologie TigerStyle
-
TigerStyle est la méthodologie d’ingénierie de TigerBeetle, publiée sur GitHub
- Il s’agit d’un « échange collectif en constante évolution à l’intersection de l’ingénierie et de l’art, des nombres et de l’intuition humaine, de la raison et de l’expérience, des premiers principes et du savoir, de la précision et de la poésie »
- Elle adopte le concept de « Biodigital Jazz » du film Tron: Legacy : l’entrelacement de l’humain et du numérique, le caractère à la fois chaotique et structuré de la « Grid », et l’expression improvisée du potentiel humain dans la technologie
- Chez TigerBeetle, cela incarne un esprit du code qui injecte non seulement de la science, mais aussi de l’art
-
L’influence de TigerStyle
- Elle propose des principes d’ingénierie et de code dérivés du Power of Ten de la NASA, destiné à écrire un code parfait
- Elle couvre aussi bien des thèmes comme la simplicité et l’élégance que des aspects appliqués comme les conventions de nommage
- Elle commence à influencer d’autres entreprises comme Resonate et Turso
- Elle a également été évoquée dans le podcast de Lex Fridman
Utilisation des assertions
-
Règle 5 du Power of Ten : l’assertion
- Il s’agit d’exprimer en même temps et de manière explicite les attentes sur le comportement du code, et non après coup
- Elle s’écrit sur une seule ligne sous forme booléenne :
assert(a > b)
-
Les règles d’assertion de TigerStyle
- Assertion sur tous les arguments de fonction, valeurs de retour, préconditions et invariants, avec au moins 2 assertions en moyenne par fonction
- Quand une assertion est importante et surprenante, elle est préférée à un commentaire
- Les relations entre constantes de compilation sont assertées afin de vérifier l’intégrité de la conception avant l’exécution du programme
- Il faut asserter non seulement ce qui doit arriver, mais aussi l’espace négatif, c’est-à-dire ce qui n’est pas censé arriver, là où peuvent surgir les bugs intéressants
La réflexion sur la performance
-
Le raisonnement et la conception du code comptent davantage que l’écriture du code elle-même
- Le meilleur moment pour résoudre la performance et obtenir de grandes victoires de type x1000, c’est la phase de conception, précisément un moment où la mesure et le profiling sont impossibles
-
Les principes de performance de TigerStyle
- Faire un peu de calcul « sur coin de table » à partir des « quatre couleurs fondamentales » (réseau, stockage, mémoire, CPU) et des « deux textures » (bande passante et latence)
- Fournir aussi des conseils tactiques : distinguer control plane et data plane, regrouper les accès par lots, extraire les hot loops dans des fonctions autonomes pour réduire les dépendances du compilateur, etc.
Mise en pratique
- TigerBeetle applique la recherche moderne à un format ancien pour offrir des garanties inédites de performance et de fiabilité
- C’est un moteur OLTP moderne combinant modélisation native crédit/débit, distribué par défaut, tolérance aux pannes de stockage et d’horloge et assurance qualité fondée sur le DST
- Il développe une véritable forme d’art autour de l’ingénierie système et du stockage, sans jamais oublier le plaisir du processus
- Grâce à une utilisation ingénieuse du DST, il a atteint le niveau Jepsen en seulement quelques années
- L’installation est simple grâce à un binaire unique, et le script d’installation minimaliste du site officiel permet de démarrer rapidement avec une simple commande
curl
6 commentaires
On comprend pourquoi une base de données n’utilise pas de nœuds distribués si l’on réfléchit à la question de savoir pourquoi Postgres est en nœud unique
Réfléchis à ce qui est plus important que les performances
Commentaire Hacker News
TigerBeetle est excellent, mais il faut garder à l’esprit que cet article a été écrit par un fonds qui a investi dans TigerBeetle lien connexe
Je vais probablement continuer à publier ce genre de posts au cours des prochains mois, et j’aimerais que les gens en discutent plus activement ; je me demande s’il vaudrait mieux ajouter un disclaimer en haut, ce n’est pas difficile à faire
L’article est clairement publié sur le site du fonds sous l’intitulé « Portfolio Spotlight », donc il faut ajuster ses attentes
Je ne vais pas spécialement commenter la manière dont c’est rédigé, mais on repère très facilement qu’il s’agit d’un article d’investisseur
Je suis fan de la quête de correction de TigerBeetle, de ses pratiques de codage et de son orientation hyper spécialisée, mais je voudrais critiquer quelques points du post
L’explication sur le multi-nœud est un peu trompeuse. Peu importe ce que disent les adeptes du cloud native, une base unique bien réglée avec un pooler de connexions peut déjà encaisser un QPS énorme. Dans une ancienne boîte, pendant une maintenance, tout le trafic a été dirigé par erreur vers une seule instance MySQL 8 RDS, et elle a absorbé 80 à 90K QPS sans difficulté. L’instance n’était même pas très grosse ; on avait simplement bien optimisé le schéma, les requêtes et le tuning ProxySQL/MySQL. En pic, avec un writer et deux read replicas, on tenait sans problème 120K QPS
Si on utilise du NVMe local au nœud sur le serveur, il est probable que la limite CPU soit atteinte avant le stockage
Pour la redondance, tout SGBDR conçu pour un environnement réseau finit de toute façon par offrir du failover et du hot standby
Le système de consensus de TigerBeetle est malin et n’a pas de dépendances externes, mais il n’essaie pas de traiter de grosses rows. Si l’on traite des milliers de transactions en un seul paquet de 1 MiB, cela peut rendre possible quelque chose qu’un SGBDR traditionnel ne pourrait pas faire
Ces critiques ne visent pas à minimiser ce qu’ils ont accompli, et je reste très impressionné par ce produit
Le point sur les limites du protocole de consensus est justement central. TigerBeetle cherche à isoler et traiter uniquement les charges purement transactionnelles, pas à remplacer toutes les bases OLGP. L’idée est de déplacer uniquement les données importantes vers une base transactionnelle séparée. On voit une approche similaire chez TurboPuffer
Il est vrai que les SGBDR modernes sont suffisamment rapides, mais le cas d’usage de TigerBeetle est un environnement spécialisé à forte contention. Ils ont effectivement montré par des tests directs que lorsque plusieurs transactions touchent un même compte, le débit global du cluster chute de façon spectaculaire. (Référence : commentaire HN associé)
J’aime beaucoup le travail de Joran et de l’équipe sur le DST, leur compréhension des systèmes distribués et leurs tests de performance, en particulier leur obsession pour la minimisation des dépendances (même si, d’une certaine manière, on pourrait aussi considérer l’OS comme une dépendance)
Mais j’ai toujours le sentiment qu’ils traitent les OLTP généralistes (qu’ils appellent OLGP) d’une manière un peu injuste. Par exemple, ils ne comparent que des transactions SQL peu performantes, comme si on n’utilisait que des verrous de ligne dans les transactions financières, ce qui donne l’impression qu’on en est resté à la conception OLTP d’il y a 50 ans
Sur la page officielle de performance, on ne peut faire descendre la contention qu’à 1 %. Je ne pense pas qu’un acteur comme Stripe considère être à 1 % de contention sur sa base OLTP
Il est possible de construire des systèmes qui anticipent la contention, la gèrent proprement et atteignent des débits transactionnels extrêmes. Ces systèmes protègent la base de données de la contention et lui permettent de continuer à scaler. En pratique, les chiffres de débit des grands systèmes de paiement sont bien supérieurs à ceux de la comparaison officielle de performance
Le marketing ignore en grande partie ces aspects et donne l’impression que tous les développeurs se contentent de déverser des transactions naïves, alors qu’en réalité la plupart sont des ingénieurs bien plus compétents. Il existe même un métier de « payments engineer » dans l’industrie du paiement
TigerBeetle est impressionnant, mais ce schéma marketing qui pousse à mal comprendre les autres systèmes OLTP me dérange
Merci pour les compliments
Vous avez dit que la base OLTP de Stripe n’était pas à 1 % de contention, mais Stripe est basé sur MongoDB. La comparaison avec un SGBDR, c’est comparer des pommes et des oranges
Sur le point de savoir si l’OS peut être vu comme une dépendance sous-jacente : j’ai travaillé sur des systèmes entièrement in-memory qui continuaient à persister même pendant un
kexec. Dans un contexte où on ne peut même pas faire de syscalls, l’OS peut tout à fait devenir une dépendanceJe serais curieux d’avoir un exemple de transaction basée sur des verrous, comparée à une approche optimisée où les conditions sont vérifiées au moment du commit
Nous avons envisagé TigerBeetle, mais nous avons rencontré les obstacles suivants
Nous utilisons Cloudflare Workers, et l’application cliente TigerBeetle n’est pas prise en charge. Lien vers l’issue Ce serait peut-être possible avec Cloudflare Containers, mais notre workflow est centré sur Workers
Il n’y a pas de fonctionnalité d’authentification. Sur un serveur (VPS, etc.), on peut seulement restreindre par IP, mais en environnement serverless, il n’y a pas d’IP fixe issue connexe
Une solution pourrait être d’utiliser Wireguard, avec des IP authentifiées par clés ECC
En réalité, dans un environnement Cloudflare Workers ou AWS Lambda, si 1 000 workers ouvrent tous une connexion à la DB, cela pose problème. On résout donc généralement cela en plaçant un proxy ou une couche de service devant la DB. Le proxy sait comment accéder à la DB, donc sur un réseau privé, il n’a pas à se soucier du problème d’auth
Si vous en discutez avec l’équipe solutions TigerBeetle, ils pourront vous proposer une solution sur mesure, comme une authentification logique via chiffrement de bout en bout
Une DB sans authentification en 2025, c’est difficile à croire. Pour une base financière, ils devraient au minimum publier sur leur site un guide expliquant comment ajouter un proxy ou une couche d’authentification. S’ils n’utilisent pas HTTP (ce qui n’est pas clair à la lecture de la documentation), tout le monde va se demander comment brancher un proxy d’auth sans HTTP. L’exposer à Internet en l’état serait très dangereux
Il y avait cette question : « En dix ans, le volume de transactions a été multiplié par plus de 1 000, et la base utilisée est un SQL vieux de 20 à 30 ans. Est-ce que ça peut tenir ? » À mon avis, oui, tout à fait.
Même un logiciel vieux de 30 ans a continué à être mis à jour, et repose sur des fondations conçues solidement à l’époque
Ici Joran (TigerBeetle). Sur des charges générales, il n’y a pas de problème, mais pour le traitement transactionnel, les verrous de lignes SQL posent problème à cause de la contention en loi de puissance (voir la loi d’Amdahl). Nous avons mis sur le site un calculateur de contention qui permet d’estimer théoriquement la limite maximale de performance ; n’hésitez pas à le consulter calculateur de contention
Il suffit de voir DNS, publié en 1983 et qui reste encore aujourd’hui l’un des fondements d’Internet : quand les bases sont solides, un système de plus de 30 ans peut tout à fait tenir. SQL est largement suffisant pour la plupart des charges
Une technologie nouvelle et élégante n’est pas toujours meilleure qu’une technologie éprouvée, usée jusqu’à la corde. Par moments, les ingénieurs logiciels donnent vraiment l’impression d’être les ingénieurs « avec le moins de mémoire » du secteur
Lorsqu’on gère des dizaines de bases dans un système distribué, on a absolument besoin de transactions distribuées (Sagas, etc.). Mais dans un contexte mono-machine, une base relationnelle reste excellente
L’ancien matériel manquait de performances, mais aujourd’hui la technologie a progressé, donc cela tourne au contraire plus vite et mieux
FoundationDB partage aussi beaucoup de points communs avec les discussions autour de TigerBeetle
Écriture du code lente, DST, absence de dépendances, environnement distribué par défaut en production, verrouillage optimiste tolérant les erreurs d’horloge, tests Jepsen très sévères, tests dans un nouveau langage (Flow), etc. On peut résoudre à peu près les mêmes problèmes avec FDB, et j’imagine que TigerBeetle est simplement mieux optimisé pour son cas d’usage
La seule raison pour laquelle FDB n’est pas populaire, c’est le manque de bonnes couches au-dessus. Cela dit, quelques personnes développent séparément des couches SQS, DynamoDB et SQLite
La vraie raison pour laquelle FDB n’est pas populaire, c’est Apple. Le produit est sorti en 2013, Apple l’a tellement aimé qu’ils ont racheté l’entreprise, puis tous les utilisateurs existants ont été abandonnés. Même après la fin de l’exclusivité, la confiance ne s’est pas rétablie
Nous travaillons avec l’équipe FDB et préparons aussi un post sur le DST
Je me demande ce qu’il s’est passé exactement après l’acquisition
C’est littéralement « the one true database »
Je me demandais « pourquoi aucun hyperscaler n’utilise FDB ? », puis j’ai fait une recherche GitHub et j’ai vu que c’était finalement passé sous Apple
J’ai récemment appliqué le style de développement de TigerBeetle à Rust, Go, etc., et je le recommande vraiment très fortement
Point d’entrée unique, dépendances proches de zéro
CI en local, tests/couverture/lint, etc. exécutables avec une seule commande
Cela m’a donné envie d’introduire des simulations avec des tests property/snapshot/swarm
Distinction rapide/lent, toutes les graines de test sont déterministes
Limites supérieures explicites + gestion par pools de ressources, ce qui rend aussi l’allocation dynamique plus facile à comprendre dans le code
C’est grâce aux vidéos et à la documentation de l’équipe TB
Le passage sur « laisser les assertions activées en production » m’a marqué
Je n’ai jamais vraiment compris pourquoi on les désactivait. Si une assertion échoue en production, il faut le savoir immédiatement
Historiquement, désactiver les assertions apportait un gain de performance. Mais aujourd’hui, quelques comparaisons supplémentaires n’ont plus vraiment d’impact
À l’origine, une assertion sert à détecter une mauvaise utilisation d’une API développeur. Au niveau des entrées utilisateur, il est plus logique de la remplacer par de la logique métier avec des messages d’erreur corrects
Il arrive qu’on veuille mettre en assertion des vérifications qui ne sont pas simples. Par exemple, vérifier qu’une liste est triée
Le but initial des assertions est d’effectuer des vérifications à la compilation ou au test. Pour un usage en production, on peut les transformer en
if. Il faut se demander siassertn’est qu’un sucre syntaxique pratiqueJ’aimerais que l’équipe TB fasse davantage connaître le modèle en partie double au-delà de la finance. C’est aussi très utile pour des actions, des billets de concert, etc. L’API est maintenant bien aboutie ; il est temps d’expliquer les usages
J’utilise beaucoup SQL comme analyste, mais je ne développe pas de code. Dans l’ensemble, je comprends l’explication de haut niveau et les avantages de performance. J’ai quelques questions a) À quoi ressemble concrètement la structure de données de TigerBeetle ? J’imagine que ce n’est pas une table classique b) Si on ne peut pas faire de requêtes SQL, comment l’utilise-t-on en pratique ? c) Comment applique-t-on le modèle en partie double à des actions, des billets, etc. ? Par exemple, si une salle détient 1 000 billets et en vend un, est-ce qu’on passe de l’inventaire au cash, puis des produits constatés d’avance aux obligations de prestation ? Ou bien n’y a-t-il aucune écriture avant la vente du billet ?
On peut implémenter une approche similaire en partie double aussi avec Postgres
La phrase « la plupart des équipes écrivent le code vite, vivent les tests comme une corvée et empilent les dépendances » était en fait la norme il y a 25 ans. Avant que Google et Facebook n’introduisent la culture du « move fast and break things », tout le monde construisait de manière méthodique, lentement et avec de bons tests. J’espère que TigerBeetle sera davantage reconnu. Le rapport Jepsen vaut aussi la lecture rapport Jepsen
Attendons 25 ans pour voir si TigerBeetle deviendra un Google, ou si un produit lent mais parfait se fera manger par un concurrent plus rapide
« Move fast and break things » était la devise de Facebook. Google, au contraire, était plutôt obsédé par les tests. Bien sûr, il faut répondre à de vrais besoins, et les ingénieurs inventent souvent trop de besoins hypothétiques, ce qui crée de l’inefficacité. Livrer vite un produit à de vrais utilisateurs, recueillir leurs retours et itérer a beaucoup plus de valeur que de peaufiner indéfiniment un produit « dans sa bulle »
Indépendamment du contenu de l’article ci-dessus, le site web de TigerBeetle lui-même est aussi assez impressionnant.
Il donne vraiment une impression de grande rapidité, et j’ai trouvé amusant le design qui cherche à présenter quelque chose de techniquement très lourd de manière légère et ludique.
Lien : https://tigerbeetle.com
Je corrige. En y regardant de plus près, il y a effectivement un côté un peu lourd. Mais je trouvais ça esthétiquement marquant, alors je le partage :)
C’est vrai. L’animation est rapide, ce qui crée un écran qui ne devient pas ennuyeux sans gêner la concentration sur le contenu. Et cela suggère aussi très fortement que TigerBeetle est extrêmement rapide haha
C’est extrêmement intéressant.
Les durées d’animation sont réglées bien plus courtes que sur les sites habituels. C’est donc aussi possible d’aborder ça de cette façon…