E-Bank

Besoin & utilisateurs

Déplacer de l’argent entre services séparés, c’est là que les systèmes distribués cassent : un virement rejoué peut s’appliquer deux fois, un service de reporting lent peut bloquer les paiements, une panne du broker peut perdre des événements. L’objectif : une banque dont les soldes restent justes malgré les répétitions, la concurrence et les pannes, et où chacun peut le constater.

Réalisation

Les services client, compte, transaction et reporting possèdent chacun leur base, s’enregistrent dans Eureka et sont exposés par une Spring Cloud Gateway qui gère rôles JWT, limitation de débit et routage. Les requêtes attendues par l’utilisateur (connexion, virements) passent en synchrone via HTTP et Feign ; le reste circule dans Kafka, que le reporting projette en tableaux de bord, rapports PDF et CSV, fil d’activité client et contrôle de réconciliation en direct. L’application Angular réunit portail client et back-office administrateur, avec 50 clients et sept mois d’historique réconcilié.

Choix technique

Rendre la justesse structurelle. Les opérations exigent une Idempotency-Key : le service de comptes conserve un reçu par opération et le grand livre impose une contrainte d’unicité en base, si bien que huit répétitions réellement concurrentes ne s’appliquent qu’une fois. Les événements passent par une outbox transactionnelle pour qu’une pause du broker ne bloque aucun paiement, les événements malformés vont dans un topic de lettres mortes, et le reporting déduplique par identifiant et rejette les instantanés périmés pour qu’un rejeu ne compte jamais deux fois.

En pratique

Le tableau de bord montre chaque compte BALANCED par rapport à son grand livre. Des scripts Python vérifient la réconciliation des données, qu’une panne Kafka ne bloque ni ne perd aucune opération, que les événements invalides atteignent le topic de lettres mortes, et mesurent les latences p50/p95 sous charge. Des tests JUnit, Mockito et Playwright sur desktop et mobile couvrent services et interface ; Kafka UI montre les topics se remplir en temps réel.

Limites actuelles

• Une démo avec des comptes générés, pas une vraie banque. Les services utilisent des bases H2 sur fichier et le Kafka local tourne sur un seul broker avec des topics non répliqués.
• Les relais de l’outbox attendent l’acquittement du broker dans les transactions. La concurrence du reporting, les migrations de base et la redondance du broker demandent du travail avant de passer à l’échelle ; les tests de reprise sont locaux, pas une preuve de capacité en production.

Sources