Plateforme Transfer Agent

L'ancien Transfer Agent de la banque ratait la fenêtre de NAV quotidienne assez souvent pour que les opérations aient construit tout un workflow Excel autour. Quand la valeur liquidative d'un fonds publie en retard, les pricing aval cassent, les agents de transfert à l'autre bout de l'Europe ratent leurs fenêtres, et quelqu'un doit écrire une lettre d'excuses. Le mandat : remplacer ce système sans perturber une seule journée de trading.

J'ai rejoint l'équipe qui reconstruisait depuis zéro, sous forme de système distribué événementiel sur AWS. La forme retenue : plus de 70 microservices autour des vraies opérations bancaires : souscriptions, rachats, règlement, calcul de NAV, reporting de conformité. Kafka comme colonne vertébrale, exactly-once sur les chemins critiques, SQS pour les fan-outs où l'ordre n'importait pas.

Ce qui était vraiment difficile

Le débit n'était pas le problème. Kafka et EKS poussent 300 000 transactions par heure sans broncher si on les laisse faire. Les vraies difficultés étaient l'ordre et la sémantique exactly-once sur les flux de souscriptions et rachats, où un événement dupliqué signifie qu'un actionnaire est facturé deux fois et que quelqu'un aux opérations doit dénouer ça à la main.

On l'a appris à nos dépens. Le premier test de charge sur des données de forme production, le pipeline NAV a accusé 6 minutes de retard. Un ingénieur junior (moi ce jour-là) a découvert que nos partitions Kafka étaient déséquilibrées. Une partition portait 40% du trafic à cause d'une collision de hash sur un identifiant de fonds fréquent. La correction a pris un après-midi. La détection précoce via une métrique de partition-skew aurait pris dix minutes.

Les compromis qu'on a payés

Kafka était le bon choix pour l'ordre, mais il est venu avec son poids opérationnel : schema registries, tuning des partitions, dashboards de lag des consumer groups, tout l'appareil. Pour la moitié de nos cas d'usage asynchrones, SQS aurait suffi. On a pris Kafka partout pour l'homogénéité, puis on s'est rabattus sur SQS dès qu'on voulait du jetable.

Postgres-par-service a bien tenu. Aurora sur les chemins de lecture lourds, Postgres RDS classique pour le reste. S3 pour l'archivage et les pistes d'audit que le régulateur veut en stockage froid pendant des années.

Ce que je signalerais pour la suite

70+ services, c'est trop pour cette charge de travail. Je livrerais quelque chose d'équivalent avec 15 à 20 si je recommençais. J'en parle dans un autre billet. L'équipe a construit le bon système ; on en a juste construit plus que ce que le domaine exigeait.

Objectifs de débit atteints avec environ 2x de marge. Déploiements indépendants : lead time passé de semaines à un jour. L'isolation des pannes fonctionne : un service dégradé arrête une ligne produit, pas la plateforme.

Étude de cas publiée sous forme anonymisée. Détails communiqués sous NDA.