이 아키텍처는 Saga 오케스트레이션 패턴을 중심으로 구성되며 이벤트 기반 백본에 의해 분리됩니다. 진입점에서 API 게이트웨이 (Kong 또는 Envoy)는 JWT 토큰을 검증하고 요청을 정책 집행 지점(PEP)으로 라우팅합니다. PEP는 **Open Policy Agent (OPA)**를 사용하여 실시간 AML 및 KYC 검사를 위해 제재 목록에 대한 질의를 수행합니다.
핵심은 크로스 레저 트랜잭션 코디네이터로, Temporal 또는 커스텀 Saga 엔진을 사용한 상태 머신으로 구현되었습니다. 이 코디네이터는 두 가지 다른 도메인에서 분산 트랜잭션을 관리합니다: 법정 화폐 원장 어댑터(ISO 20022 메시지를 통해 SWIFT, ACH, 또는 SEPA와 통합)와 블록체인 어댑터(Alchemy 또는 Infura를 통해 EVM 체인을 지원하고 Horizon API를 통해 Stellar 지원).
공공 블록체인에서는 사용할 수 없는 2PC 없이 원자성을 보장하기 위해 보상 거래를 포함한 Saga 패턴을 사용합니다. 코디네이터는 먼저 "법정화폐 차감" 로컬 트랜잭션을 실행한 다음, "스테이블코인 발행/전송" 로컬 트랜잭션을 수행합니다. 후자가 실패할 경우, 전자는 "법정화폐 입금" 거래로 보상됩니다. 이벤트 소싱을 통해 모든 상태 변경 사항이 PostgreSQL에 지속적으로 저장되고 Kafka에 게시되어 감사가 가능합니다.
유동성 관리는 지리적으로 분산된 캐시(Redis 클러스터)와 Cassandra에 대한 WAL 백킹을 이용하여 지역 간 일관성을 유지합니다. 마이크로서비스 간의 gRPC 연결로 낮은 대기시간을 보장하며, Prometheus와 Grafana가 가시성을 제공합니다. 전체 스택은 Kubernetes에서 실행되며 Istio를 통해 서비스 메쉬 기능이 제공되고, 구성 요소 간에 mTLS를 보장합니다.
CrossBridge Payments에서 우리는 ACH를 사용하는 미국 고객이 독일 수령인에게 SEPA 크레딧으로 즉시 송금할 수 있도록 하는 것이 필요했습니다. 이는 Ethereum과 Stellar에서 USDC 스테이블코인 브리지를 통해 우회하여 통신 은행의 지연을 줄이는 것이 었습니다. 주요 도전 과제는 원자성을 보장하는 것이었습니다: ACH 차감이 성공한 후 블록체인 트랜잭션이 실패할 경우 고객은 자금을 잃게 되지만, 블록체인 최종 확정에는 Ethereum에서 12초가 걸리며 ACH 정산은 T+1이지만 차감은 즉시 이루어집니다.
우리는 세 가지 아키텍처 접근 방식을 평가했습니다. 첫 번째 옵션은 법정화폐와 암호화폐 모두를 보관하는 중앙 집중식 오라클이 신뢰할 수 있는 중개 역할을 수행하는 것이었습니다. 이 방법은 조정이 간편하고 지연 시간을 밀리초 수준으로 줄였지만, 허용할 수 없는 상대방 위험을 초래하고 특정 관할권에서 분산 보관에 대한 규제 요건을 충족하지 못했습니다.
두 번째 옵션은 법정 은행과 블록체인 간의 신뢰 없는 원자 교환을 위해 **해시 시간 잠금 계약 (HTLC)**를 제안했습니다. 그러나 전통적인 은행 레일은 온체인에서 해시를 검증할 수 있는 암호화 원시가 부족하고, 타임아웃 메커니즘이 적극적인 클라이언트 참여를 요구하여 사용자 경험을 저하시켰기 때문에 실행 가능하지 않았습니다.
우리는 궁극적으로 Apache Kafka와 Temporal을 사용하는 Saga 오케스트레이션과 이벤트 소싱을 선택했습니다. 이 접근 방식은 법정 차감과 암호화폐 발행을 Saga 내의 독립적인 로컬 트랜잭션으로 처리합니다. 오케스트레이터는 처음에 ACH 어댑터를 통해 자금을 마스터 에스크로 계좌에 잠그고, 그 다음에 Stellar에서 USDC 전송을 시작했습니다(5초 최종 확인이 선택됨). 암호화 단계가 실패하면 오케스트레이터는 ACH 잠금을 되돌리는 보상 거래를 트리거했습니다.
그 결과, 800ms 평균 UI 확인 시간으로 99.95%의 성공률을 달성하고, 모든 규제 감사 로그가 PostgreSQL에 저장되었으며, 원자성 실패로 인한 고객 자금 손실이 제로였습니다.
서버가 HTTP 연결을 몇 분 동안 열지 않고 REST API 클라이언트의 동기적 기대와 비동기적 확률적 블록체인 네트워크의 최종성을 어떻게 조화시키나요?
많은 후보자들은 블록체인 확인이 이루어질 때까지 긴 폴링 또는 블록킹 HTTP 요청을 제안합니다. 그러나 이는 서버 스레드를 소진시키고 게이트웨이 타임아웃을 유발합니다. 올바른 접근 방식은 CQRS 패턴과 이벤트 소싱을 결합한 것입니다. 초기 정산 요청은 즉시 202 Accepted 상태와 고유한 트랜잭션 상관 ID로 반환됩니다. 클라이언트는 WebSocket 또는 서버 전송 이벤트 (SSE) 엔드포인트에 구독하거나 Redis에 백업된 경량 상태 엔드포인트를 폴링합니다. 백엔드는 블록체인 확인을 비동기적으로 처리합니다. Saga가 터미널 상태(완료 또는 보상)에 도달하면 상태가 클라이언트에게 푸시됩니다.
하류 은행 API(JPMorgan Access 또는 Stripe Treasury)가 타임아웃을 반환할 때 법정 차감의 정확한 실행을 보장하는 전략은 무엇이며, 자금이 실제로 이동했는지에 대한 모호함이 남습니다?
후보자들은 종종 재시도가 안전하다고 가정하거나 멱등성 키만으로는 충분하다고 잘못 추정합니다. 견고한 솔루션은 PENDING 상태 머신을 가진 멱등성 원장을 PostgreSQL에 구현하는 것입니다. 외부 API를 호출하기 전에 서비스는 결정론적 키(SHA-256의 트랜잭션 ID + 타임스탬프 버킷)로 의도 레코드를 작성합니다. API가 타임아웃되면 배경 Saga 작업자가 은행의 멱등성 질의 엔드포인트를 질의합니다(또는 Webhook 조정을 사용). 명시적인 확인이나 부정 이후에만 상태가 SUCCESS 또는 FAILED로 전환됩니다.
고빈도 차익 거래 봇이 REST API와 수신 블록체인 입금 이벤트를 통해 동일한 USDC 준비금을 동시에 액세스할 때 유동성 분산과 이중 지출을 어떻게 방지하나요?
이것은 데이터베이스 수준에서 낙관적 잠금과 중요 섹션에 대한 분산 잠금을 요구합니다. 유동성 서비스는 PostgreSQL에서 버전이 관리되는 행을 유지하며, 모든 업데이트는 버전을 증가시킵니다. 인출이 시도될 때, 시스템은 버전을 확인합니다. 동시에 블록체인 이벤트가 행을 수정했으면(버전 불일치), 트랜잭션을 재시도합니다. 핫 경로의 경우, 잔액을 확인하기 전에 Redis Redlock이 확보되어 순차적 접근을 보장합니다. 또한, 서킷 브레이커(Resilience4j)가 유동성 풀의 경합 비율을 모니터링합니다.