このアーキテクチャは、イベント駆動型のバックボーンでデカップルされたサガオーケストレーションパターンに基づいています。入口では、APIゲートウェイ（KongまたはEnvoy）がJWTトークンを検証し、リクエストをポリシーエンforcementポイント（PEP）にルーティングし、オープンポリシーエージェント（OPA）を使用して、制裁リストに対するリアルタイムのAMLおよびKYCチェックをコーリングします。
コアは、Fiat Ledger Adapter（SWIFT、ACH、またはSEPAとISO 20022メッセージングを介して統合）とBlockchain Adapter（AlchemyまたはInfuraを介してEVMチェーンをサポート、Horizon APIを介してStellarをサポート）で構成される、クロスレジャートランザクションコーディネーターです。
公開ブロックチェーン上で利用できない2PCなしでの原子性を確保するために、補償トランザクションを用いたサガパターンを採用しています。コーディネーターは、まず「フィアットデビット」ローカルトランザクションを実行し、その後「スターブルコインの鋳造/転送」ローカルトランザクションを実行します。後者が失敗した場合は、前者が「フィアットクレジット」トランザクションで補償されます。イベントソーシングにより、すべての状態変更がPostgreSQLに保存され、監査可能性のためにKafkaに公開されます。
流動性管理は、クロスリージョンの一貫性を保つために、Cassandraにバックアップされた地理的に分散したキャッシュ（Redisクラスター）を使用します。マイクロサービス間のgRPC接続は低遅延を保証し、PrometheusとGrafanaは可視性を提供します。全体のスタックは、Kubernetes上で実行され、Istioによりサービスメッシュ機能が提供され、コンポーネント間のmTLSが保証されています。
CrossBridge Paymentsでは、米国の顧客がACHを使用して、ドイツの受取人がSEPAクレジットを受け取るための即座の送金を可能にするという重要な要件に直面しました。これは、対応銀行の遅延を減少させるためにEthereumとStellarのUSDCスターブルコインブリッジを介してルーティングされます。主要な課題は原子性を確保することでした。すなわち、ACHデビットが成功した後にブロックチェーントランザクションが失敗した場合、顧客は資金を失うことになりますが、Ethereumではブロックチェーンの最終性に12秒かかる一方で、ACHの決済はT+1ですがデビットは即時です。
私たちは三つのアーキテクチャアプローチを評価しました。最初の選択肢は、フィアットと暗号の両方を保管する集中型オラクルが信頼できる仲介者として機能するものでした。これは調整を簡略化し、ミリ秒単位での待機時間を短縮しましたが、受け入れられないカウンターパーティリスクをもたらし、特定の法域における分散型の保管に関する規制要件を満たすことに失敗しました。
二つ目の選択肢は、フィアット銀行とブロックチェーン間での信頼性のない原子スワップのための**ハッシュタイムロック契約（HTLC）**を提案しました。しかし、伝統的な銀行ネットワークがオンチェーンでハッシュを検証するための暗号プリミティブを欠いているため、これは実現不可能であることが判明しました。また、タイムアウトメカニズムが要求される顧客の積極的な参加を必要とする悪いユーザーエクスペリエンスを生み出しました。
最終的に、私たちはApache KafkaとTemporalを使用したサガオーケストレーションとイベントソーシングを選択しました。このアプローチでは、フィアットデビットと暗号鋳造をサガ内の別々のローカルトランザクションとして扱いました。オーケストレーターはまずACHアダプタを介してマスターエスクローアカウントに資金をロックし、次にStellar上でUSDCの転送を開始しました（5秒の最終性のために選択）。暗号ステップが失敗した場合、オーケストレーターはACHロックを逆転させる補償トランザクションをトリガーしました。
その結果、99.95%の成功率と800msの平均UI確認時間が実現され、PostgreSQLに保存された完全な規制監査トレイルが確保され、原子性の失敗による顧客資金の損失はゼロでした。六か月のパイロット中にです。
REST APIクライアントの期待の同期性と、HTTP接続を数分間オープンにせずに公共ブロックチェーンネットワークの非同期で確率的な最終性をどう調和させますか？
多くの候補者は、ブロックチェーン確認までロングポーリングやブロッキングHTTPリクエストを提案しますが、これはサーバースレッドを枯渇させ、ゲートウェイのタイムアウトを引き起こします。正しい方法は、CQRSパターンとイベントソーシングを組み合わせたものです。初期の決済リクエストは即座に202 Acceptedステータスとユニークなトランザクション相関IDを返します。クライアントはWebSocketまたはサーバー送信イベント（SSE）エンドポイントを購読するか、Redisにバックアップされた軽量のステータスエンドポイントをポーリングします。バックエンドはKafkaコンシューマーを介してブロックチェーン確認を非同期で処理します。サガが終端状態（完了または補償）に達すると、ステータスがクライアントにプッシュされます。
下流の銀行API（JPMorgan AccessまたはStripe Treasury）がタイムアウトを返す場合、フィアットデビットの正確な一度の実行をどのように保証しますか？資金が実際に移動したかどうか不明な場合です。
候補者はしばしばリトライが安全であるか、あるいは冪等キーだけで十分であると誤って考えます。堅牢なソリューションは、PENDING状態マシンを持つ冪等性台帳をPostgreSQLを使用して実装します。外部APIを呼び出す前に、サービスはトランザクションID + タイムスタンプバケットのSHA-256という決定論的キーで意図記録を書き込みます。APIがタイムアウトした場合、バックグラウンドのサガワーカーは銀行の冪等性照会エンドポイントを照会します（またはWebhook調整を使用します）。明示的確認または否定があるまで状態はSUCCESSまたはFAILEDに遷移しません。
高頻度アービトラージボットがREST APIおよび入金ブロックチェーンイベントを介して同時に同じUSDC準備金にアクセスする際に、流動性の断片化と二重支出をどのように防ぎますか？
これは、データベースレベルでの楽観的ロックと重要なセクションに対する分散ロックを必要とします。流動性サービスはPostgreSQLにバージョン付き行を維持し、任意の更新はバージョンをインクリメントします。引き出しが試行されると、システムはバージョンを確認します。もし同時のブロックチェーンイベントが行を変更している場合（バージョン不一致）、トランザクションは再試行されます。ホットパスでは、残高を確認する前にRedis Redlockを取得し、逐次アクセスを保証します。さらに、回路ブレイカー（Resilience4j）が流動性プールの競合率を監視します。