nicolas-ha.com · English

Migrer le cœur d'une banque sans arrêter la production.

Griffin Bank, 2022 à 2025, pendant l'obtention de la licence bancaire. La file de messages au centre de la banque, en trois générations.

Le problème : la banque est un système de messages. Il fallait passer sa file centrale de Kafka à FoundationDB, banque en service.

1Le schéma

Les procs, le runner et la file sur FoundationDB, Kafka avant ; le journal d'audit et le cron distribué ; trois générations
Dessiné dans Excalidraw.
le code métierle runner et ses générationsla filebâti dessus

2Ce que j'ai construit

  1. Le runner : les « procs » de la banque sont des fonctions pures, chaque message déclaré en clojure.spec ; j'ai écrit le runner à chaque génération.
  2. v1, la migration : partie de la preuve de concept du CTO, j'ai écrit les runners et tout l'outillage de migration, puis mené la migration.
  3. v2 et v3, réécrites de zéro : la concurrence, puis l'équité et l'isolation entre charges.
    • D'après Dynamo (Amazon, SOSP 2007 : l'anneau de hachage cohérent) et QuiCK (Apple, SIGMOD 2021).
  4. Le cron distribué : posé sur la file, chaque tâche planifiée tourne une seule fois dans le cluster.
  5. Le journal d'audit : il indexe chaque message ; la liste des specs est la liste de ce qu'il indexe.

3Le résultat

  1. Zéro erreur, zéro incident à la bascule.
    • Si calme que j'ai d'abord cru que la bascule n'avait pas eu lieu ; le VP l'a cité en réunion générale.
  2. Un tiers du stockage d'audit en moins, en rendant son historique optionnel.
  3. Des tests générés : un framework sur clojure.spec et test.check, dans la lignée de FoundationDB, qui trouve vite les bugs.

4Mon rôle

  1. Ingénieur logiciel senior, sur la plateforme.
    • J'ai participé à la création d'équipes pendant la croissance de la banque.
  2. Tech talks internes, RFC et mentorat : les files de messages et l'équité, les crons distribués.

5La vidéo

Une minute, voix de synthèse, sous-titrée.