Microservices : Betclic parie sur une architecture orientée événements
Leader des paris en ligne, Betclic a transformé son infrastructure pour passer d’une architecture fortement couplée, où la performance était dictée par le service le plus lent, à une approche de microservices et de cloud public
Acteur majeur du jeu en ligne présent en France, en Pologne et au Portugal, Betclic génère un trafic Web qui se caractérise par de gros pics de charge.
Guillaume Lannebere, AWS Solutions Architect, au sein de Betclic raconte : « Une heure avant le match, les utilisateurs se connectent à la plateforme pour parier, puis tous les utilisateurs se reconnectent en même temps à la fin du match pour découvrir leurs gains. Nous devons alors payer les joueurs, enregistrer les nouveaux paris et alimenter le marketing, l’analytique. Tout se passe dans les 15 minutes après la fin du match et cela représente un milliard d’événements chaque mois ! »
En 2019, l’entreprise entreprend la refonte de son infrastructure pour passer d’une architecture fortement couplée, où la performance était dictée par le service le plus lent, à une approche de microservices et de cloud public. « Pour migrer, notre première démarche a été de concevoir une architecture orientée événements s’appuyant sur un bus d’événements pour faire communiquer tous nos domaines entre eux. »
Parmi les exigences de Betclic, ce bus assure la lecture multiple, un événement peut être lu par tous les domaines applicatifs, les événements devaient pouvoir être filtrés et offrir une fonction de reprise sur erreur et de remise au moins une fois.
Microservices et cloud public
« Nous voulions une solution indépendante du langage de programmation, car nous codons en différents langages et une solution qui vienne se placer au-dessus des langages de programmation. Enfin, nous préférions une solution entièrement managée, car nous ne sommes pas une entreprise d’infrastructure. » Bien entendu, Betclic souhaitait une montée à l’échelle automatique.
« Notre trafic n’est pas prédictible : nous avions besoin d’autoscaling pour faire face aux pics de trafic de fin de match, avec une faible latence et une haute disponibilité. En 2019, la solution AWS EventBridge n’était pas encore disponible, donc nous avons fait le choix de SNS (Simple Notification Service) et SQS (Amazon Simple Queue Service). Cela nous a amenés à implémenter nous-mêmes les fonctionnalités qui nous manquaient. »
L’architecte s’interroge aujourd’hui sur une migration vers EventBridge qui dispose de toutes les fonctionnalités requises par l’infrastructure orientée événement de Betclic. »
Alain Clapaud
Image : DR @betclic
