L'architecture repose sur un modèle de Saga Orchestration découplé par une infrastructure Event-Driven. À l'entrée, une API Gateway (Kong ou Envoy) valide les jetons JWT etroute les demandes à un Policy Enforcement Point (PEP), qui interroge un Policy Decision Point (PDP) à l'aide de l'Open Policy Agent (OPA) pour des vérifications AML et KYC en temps réel contre les listes de sanctions.
Le cœur de l'architecture est le Coordinateur de Transaction Inter-Réseaux, implémenté comme une machine d'état utilisant Temporal ou un moteur Saga personnalisé sur Apache Kafka. Ce coordonnateur gère la transaction distribuée à travers deux domaines distincts : l’Adaptateur de Ledger Fiat (s'intégrant avec SWIFT, ACH ou SEPA via le messaging ISO 20022) et l’Adaptateur Blockchain (supportant les chaînes EVM via Alchemy ou Infura, et Stellar via l'API Horizon).
Pour l'atomisme sans 2PC (qui est indisponible sur les blockchains publiques), nous utilisons le modèle de Saga avec des transactions compensatoires. Le coordonnateur exécute d'abord la transaction locale "débit fiat", puis la transaction locale "frapper/transférer stablecoin". Si cette dernière échoue, la première est compensée par une transaction "crédit fiat". La sourcing d'événements garantit que tous les changements d'état sont persistés dans PostgreSQL et publiés sur Kafka pour l'auditabilité.
La gestion de la liquidité utilise un Cache Géographiquement Distribué (Redis Cluster) avec un support WAL vers Cassandra pour la cohérence inter-régionale. Les connexions gRPC entre microservices assurent une faible latence, tandis que Prometheus et Grafana offrent la visibilité. L'ensemble de la pile s'exécute sur Kubernetes avec Istio pour les capacités de maillage de services, garantissant mTLS entre les composants.
Chez CrossBridge Payments, nous avons fait face à un besoin critique d'activer un envoi instantané d'un client américain utilisant ACH vers un destinataire allemand recevant des crédits SEPA, acheminés par le biais d'un pont stablecoin USDC sur Ethereum et Stellar pour réduire les délais bancaires correspondants. Le principal défi était d'assurer l'atomisme : si la transaction blockchain échouait après le débit ACH réussi, le client perdrait des fonds, alors que la finalité blockchain prend 12 secondes sur Ethereum tandis que le règlement ACH est T+1 mais les débits sont immédiats.
Nous avons évalué trois approches architecturales. La première option impliquait un Oracle Centralisé qui détenait la garde à la fois des fiat et des cryptos, agissant comme un intermédiaire de confiance. Bien que cela simplifie la coordination et réduise la latence à des millisecondes, cela a introduit un risque inacceptable de contrepartie et n'a pas respecté les exigences réglementaires pour la garde décentralisée dans certaines juridictions.
La seconde option proposait des Contrats de Temps Verrouillés par Hash (HTLC) pour des échanges atomiques sans confiance entre la banque fiat et la blockchain. Cependant, cela s'est avéré irréalisable car les rails bancaires traditionnels manquent de primitives cryptographiques pour vérifier les hashes sur la chaîne, et les mécanismes de délai créaient une mauvaise expérience utilisateur nécessitant la participation active des clients.
Nous avons finalement sélectionné la Saga Orchestration avec Sourcing d'Événements utilisant Apache Kafka et Temporal. Cette approche traitait le débit fiat et le minting crypto comme des transactions locales séparées au sein d'une Saga. L'orchestrateur a d'abord verrouillé des fonds dans un compte séquestre principal via l'adaptateur ACH, puis a initié le transfert USDC sur Stellar (choisi pour sa finalité de 5 secondes). Si l'étape crypto échouait, l'orchestrateur déclenchait une transaction compensatoire pour inverser le verrouillage ACH.
Le résultat était un taux de succès de 99,95 % avec un temps de confirmation moyen de l'UI de 800 ms, des pistes d'audit réglementaires complètes stockées dans PostgreSQL, et aucune perte de fonds client due à des échecs d'atomisme pendant le pilote de six mois.
Comment réconciliez-vous la nature synchrone des attentes des clients d'API REST avec la finalité asynchrone et probabiliste des réseaux blockchain publics sans maintenir les connexions HTTP ouvertes pendant des minutes ?
Beaucoup de candidats suggèrent le long-polling ou des requêtes HTTP bloquantes jusqu'à la confirmation de la blockchain, ce qui épuise les threads serveur et déclenche des délais d'attente de passerelle. L'approche correcte implique le modèle CQRS combiné avec le Sourcing d'Événements. La demande de règlement initiale renvoie immédiatement un statut 202 Accepted et un ID de corrélation de transaction unique. Le client s'abonne à un point de terminaison WebSocket ou à des Server-Sent Events (SSE), ou interroge un point de terminaison d'état léger soutenu par Redis. L'arrière-plan traite la confirmation de la blockchain de manière asynchrone via des consommateurs Kafka. Une fois la Saga atteignant un état terminal (terminé ou compensé), le statut est poussé au client.
Quelle stratégie garantit l'exécution exactement une fois des débits fiat lorsque l'API bancaire en aval (JPMorgan Access ou Stripe Treasury) retourne un délai d'attente, laissant l'ambiguïté sur la réelle transmission des fonds ?
Les candidats supposent souvent à tort que les essais sont sûrs ou que les clés d'idempotence suffisent à elles seules. La solution robuste implémente un Registre d'Idempotence utilisant PostgreSQL avec une machine d'état PENDING. Avant d'appeler l'API externe, le service écrit un enregistrement d'intention avec une clé déterministe (SHA-256 de l'ID de transaction + timestamp bucket). Si l'API expire, un worker Saga en arrière-plan interroge l'endpoint de requête d'idempotence de la banque (ou utilise la réconciliation par Webhook). Ce n'est qu'après confirmation ou déni explicite que l'état passe à SUCCESS ou FAILED.
Comment empêchez-vous la fragmentation de la liquidité et le double dépense dans la piscine de liquidité partagée lorsque des bots d'arbitrage à haute fréquence accèdent simultanément aux mêmes réserves USDC via l'API REST et les événements de dépôt blockchain entrants ?
Cela nécessite un Verrouillage Optimiste au niveau de la base de données et un Verrouillage Distribué pour des sections critiques. Le service de liquidité maintient des lignes avec des versions dans PostgreSQL ; toute mise à jour incrémente la version. Lorsqu'un retrait est tenté, le système vérifie la version. Si un événement blockchain concurrent a modifié la ligne (non concordance de version), la transaction est réessayée. Pour le chemin chaud, un Redis Redlock est acquis avant de vérifier les soldes, garantissant un accès séquentiel. De plus, un Disjoncteur (Resilience4j) surveille le ratio de contention de la piscine de liquidité.