Dans un article précédent, nous avons expliqué ce qu’est le DCB (Dynamic Consistency Boundary) : une façon d’imposer, avec l’event sourcing, des règles métier qui portent sur plusieurs choses à la fois, sans les détours qui rendaient cela autrefois coûteux et source d’erreurs. En résumé : au lieu de figer vos frontières de cohérence à l’avance, vous les définissez à chaque action, sous forme de requête sur vos événements. Flexible, donc. Cet article porte sur le revers de la médaille qui revient toujours dans la conversation : la performance de l’event sourcing DCB.
Car dès que vous construisez quelque chose de flexible, la même question suit presque automatiquement, de la part de chaque développeur expérimenté comme de chaque dirigeant qui a un jour subi un logiciel lent : est-ce que ce n’est pas lent ? Et cher ?
La question est légitime. Alors nous ne l’avons pas tenu pour acquis. Nous l’avons testé.
Flexible ou rapide : en général, il faut choisir
En logiciel, une loi agaçante s’applique souvent : plus vous rendez les règles de cohérence flexibles, plus le système doit se coordonner en interne, et plus il ralentit facilement sous la charge. Beaucoup d’équipes choisissent donc un camp dès le départ : soit flexible, soit rapide.
La question qui nous intéressait était simple. Le DCB échappe-t-il à ce compromis, ou rembourse-t-on la flexibilité en vitesse ?
Comment nous avons testé la vitesse de l’event sourcing DCB
Nous avons construit notre propre implémentation du DCB (en Go) au-dessus d’une base PostgreSQL tout à fait ordinaire, et nous l’avons mise à l’épreuve avec des milliers d’écritures simultanées. Un détail compte : tous les contrôles se font dans la base de données elle-même, pas dans l’application. Le logiciel reste ainsi simple, et vous pouvez en faire tourner plusieurs copies côte à côte sans que la cohérence en souffre.
Tout tournait sur une infrastructure européenne (Scaleway, avec qui nous travaillons depuis des années), du serveur de base de données le moins cher jusqu’à une machine costaude à 32 cœurs.
Résultat : l’event sourcing DCB est rapide et flexible
La réponse courte : oui, flexible et rapide à la fois, c’est possible.
- Même sur le serveur de base de données le moins cher de Scaleway, nous avons traité quelques milliers d’écritures cohérentes par seconde.
- La machine bien plus chère et plus puissante était plus rapide, mais loin d’être proportionnellement : environ 150 fois le prix pour moins de 2 fois la vitesse. Le goulot d’étranglement ne se trouve en effet pas dans le DCB, mais dans la vitesse à laquelle une base de données peut tout simplement écrire sur disque. Plus de matériel n’y change que peu de chose.
- Et la cohérence complète a tenu bon. Aucun compromis de ce côté-là.
Et ça tient à mesure que la charge augmente. Plus il y a d’utilisateurs simultanés, plus il y a d’écritures par seconde, jusqu’à ce que la base de données elle-même devienne la limite naturelle :
Autrement dit : vous n’avez pas besoin d’une infrastructure chère et exotique pour que ça fonctionne. Un serveur de base de données européen ordinaire suffit largement pour la vitesse d’écriture dont la plupart des entreprises auront jamais besoin.
Soyons honnêtes : ce n’est pas une baguette magique
C’est notre façon de travailler : nous disons aussi quand quelque chose n’est pas le meilleur choix.
Si l’activité devient vraiment extrême sur une seule et même donnée (pensez à un très grand nombre de personnes qui essaient de modifier exactement le même objet au même instant), le système doit traiter ces actions l’une après l’autre. Pour un scénario aussi exceptionnel, « assez rapide » dépend de votre situation. Nous cherchons alors ensemble la solution adaptée.
Mais pour la grande majorité des vrais processus métier (facturation, stock, réservations, un pipeline CRM), vous restez largement en dessous. Là, c’est tout simplement rapide.
Comment nous abordons cela chez Tandem
Nous ne nous fions ni aux promesses ni aux articles de blog des autres. Nous testons nous-mêmes les fondations avant de les utiliser chez un client, et ce benchmark en est un exemple.
Concrètement, cela veut dire que nous utilisons l’event sourcing là où l’historique compte vraiment, que nous le faisons tourner sur une infrastructure européenne, et que nous choisissons les frontières (les tags, voir l’article précédent) avec soin pour que ça reste rapide. C’est justement sur ce dernier choix que l’expérience fait la différence.
Le résultat pour vous : un logiciel sur mesure qui grandit avec votre entreprise et reste abordable à faire tourner, sans devoir choisir entre flexibilité et vitesse.
Vous voulez les chiffres en détail ?
Cet article est le résumé pour ceux qui veulent surtout la conclusion. L’analyse technique complète, avec toutes les mesures, les graphiques et les quatre stratégies que nous avons comparées, je l’ai publiée sur mon blog personnel (en anglais) : Can DCB event sourcing be fast and flexible? A Postgres benchmark.
En bref
Avec l’event sourcing DCB, vous n’avez pas à choisir entre flexible et rapide. Sur une infrastructure européenne ordinaire, vous avez les deux, avec une cohérence complète et sans matériel coûteux. La flexibilité que le DCB vous offre ne vous coûte donc pas la vitesse que vos clients attendent.
Vous vous demandez si c’est adapté à votre projet ? Un échange sans engagement avec Tandem Studio ne vous coûte rien et vous apporte au minimum une réponse claire.
