Les décisions d'architecture derrière le cœur de wallet et les systèmes satellites d'un grand e-wallet vietnamien — et ce que nous ferions différemment.
« Microservices » est souvent compris comme tout découper. En pratique, la valeur ne tient pas au nombre de services mais au tracé des bonnes frontières — autour des capacités métier, pas de l'organigramme.
En concevant le cœur de wallet et les systèmes satellites d'un e-wallet à l'échelle nationale, nous avons traité des millions de transactions sous des exigences strictes de cohérence, de sécurité et d'évolutivité. Voici quelques leçons qui ont survécu au contact de la production.
1. Les frontières de service suivent le métier
Un service doit posséder une capacité métier complète et ses données. Si deux services doivent changer ensemble à chaque mise à jour, c'est le signe d'une mauvaise frontière — ils devraient n'en faire qu'un.
2. Event-driven pour ce qui n'a pas besoin d'être synchrone
- Les mouvements d'argent exigent une forte cohérence — traitez-les de façon synchrone, avec idempotence.
- Notifications, réconciliation, analytique — poussez-les via des événements, traitez-les de façon asynchrone pour ne pas bloquer le flux principal.
- Chaque événement est un fait survenu, pas une commande — de nouveaux consommateurs peuvent s'ajouter sans toucher au producteur.
3. API-first avec des contrats clairs
Définir les contrats d'API avant de coder permet aux équipes de travailler en parallèle et réduit l'intégration douloureuse de fin de projet. Chaque changement de contrat est versionné et ne casse jamais les consommateurs existants.
Les microservices ne vous donnent pas de la vitesse gratuitement — ils échangent de la complexité dans le code contre de la complexité dans l'exploitation. Ne payez ce coût que lorsque l'échelle l'exige vraiment.
Ce que nous ferions différemment
Commencer avec moins de services. Un monolithe bien modularisé, découpé progressivement à mesure que la pression de mise à l'échelle apparaît, est presque toujours moins coûteux qu'un découpage trop précoce suivi de fusions ultérieures. L'infrastructure d'observabilité devrait exister avant le deuxième service, pas après le dixième.