Mimari (IT)Sistem Mühendisi

Küresel dağıtılmış, gerçek zamanlı çapraz defter ödeme sistemi tasarlayın; geleneksel bankacılık ödeme yolları (SWIFT, ACH, SEPA) ile heterojen blok zincir ağları arasında atomik bir köprü oluşturarak, programlanabilir politika uygulamaları aracılığıyla düzenleyici uyum sağlarken, asenkron Bizans konsensüs mekanizmalarına rağmen alt saniye nihai onaylarını koruyarak, merkezi bir temizleme evi bağımlılıklarını ortadan kaldırmadan, muhabir bankacılık düğümleri arasında otomatik likidite yeniden dengelemesi uygulayın?

Hintsage yapay zeka asistanı ile mülakatları geçin

Soruya Cevap

Mimari, Saga Orkestrasyonu deseninin Olay-İdrak omurgası ile birbirinden ayrıldığı bir merkeziyete dayanır. Giriş noktasında, bir API Gateway (Kong veya Envoy), JWT jetonlarını doğrulamaktadır ve talepleri bir Politika Uygulama Noktasına (PEP) yönlendirir; burası da Açık Politika Aracı (OPA) kullanarak gerçek zamanlı AML ve KYC kontrolleri yapmak için bir Politika Karar Noktasına (PDP) sorgulama yapmaktadır.

Temel, Çapraz Defter İşlem Koordinatörü olup, Temporal veya özel bir Saga motoru kullanılarak bir durum makinesi olarak uygulanır. Bu koordinatör, iki farklı alan arasında dağılmış işlemleri yönetir: Fiat Defter Adaptörü (SWIFT, ACH veya SEPA ile ISO 20022 mesajlaşması aracılığıyla entegre) ve Blok Zincir Adaptörü (EVM zincirlerini Alchemy veya Infura, Stellar'ı ise Horizon API üzerinden destekler).

Atomiklik için 2PC (kamusal blok zincirlerde mevcut değildir) uygulamaktayız, bu yüzden telafi edici işlemlerle birlikte Saga desenini kullanıyoruz. Koordinatör önce "fiat borçlandır" yerel işlemini, daha sonra "stablecoin basma/transfer etme" yerel işlemini gerçekleştirir. Eğer ikincisi başarısız olursa, ilki bir "fiat alacak" işlemi ile telafi edilir. Olay kaynaklı yapı, tüm durum değişikliklerinin PostgreSQL'de saklanmasını ve Kafka'ya yayınlanmasını sağlar.

Likidite yönetimi, bölgesel tutarlılık sağlamak için Coğrafi Dağıtılmış Önbellek (Redis Cluster) ile WAL ile desteklenmiştir Cassandra. gRPC bağlantıları, mikro hizmetler arasında düşük gecikme sağlar, Prometheus ve Grafana gözlemlenebilirlik sağlar. Tüm yığın, bileşenler arasında mTLS sağlamak için Kubernetes üzerinde Istio ile çalışır.

Hayattan Bir Durum

CrossBridge Payments'de, ACH kullanarak bir Amerikan müşteriden Almanya'da SEPA kredisi alan bir alıcıya anında havale yapılabilmesi için kritik bir gereklilikle karşılaştık; bu işlem, muhabir bankacılık gecikmelerini azaltmak için Ethereum ve Stellar'da bir USDC stablecoin köprüsü aracılığıyla yönlendirilmiştir. Birincil zorluk, atomikliği sağlamaktı: eğer blok zinciri işlemi, ACH borçlandırılması başarılı olduktan sonra başarısız olursa, müşteri fon kaybına uğrayacaktı, ancak blok zincirinin nihai onayı Ethereum'da 12 saniye sürerken, ACH işlemleri T+1 ama borçlandırmalar hemen gerçekleşiyordu.

Üç mimari yaklaşımı değerlendirdik. İlk seçenek, hem fiat hem de kripto para üzerinde tasarruf sahibi olan bir Merkezi Oracle kullanmaktı; bu, güvenilir bir aracı olarak işlev gördü. Bu, koordinasyonu basitleştirirken ve gecikmeyi milisaniyelere indirdi, ancak kabul edilemez karşı taraf riski oluşturdu ve belirli yargı alanlarında merkezi olmayan saklama için düzenleyici gereklilikleri yerine getiremedi.

İkinci seçenek, fiat banka ve blok zinciri arasında güvenilmez atomik değişim için Hash Time-Locked Contracts (HTLC) önermektedir. Ancak, geleneksel bankacılık yollarında, blok zinciri üzerinde hash'leri doğrulamak için kriptografik temel öğeler yoktu ve zaman aşımı mekanizmaları, aktif müşteri katılımı gerektirerek kötü bir kullanıcı deneyimi oluşturdu.

Sonunda, Apache Kafka ve Temporal kullanarak Saga Orkestrasyonu ile Olay Kaynağı seçtik. Bu yaklaşım, fiat borçlandırmasını ve kripto para basımını bir Saga içinde ayrı yerel işlemler olarak ele aldı. Orkestratör önce fonları ACH adaptörü aracılığıyla bir ana teminat hesabında kilitledi, ardından Stellar üzerindeki USDC transferini başlattı (5 saniye nihai onayı seçildi). Eğer kripto adımı başarısız olursa, orkestratör, ACH kilidini geri çevirmek için telafi edici bir işlem tetiklerdi.

Sonuç, %99.95 başarı oranı ile 800ms ortalama UI onay süresi, PostgreSQL'de saklanan tam düzenleyici denetim izleri ve atomiklik hataları nedeniyle müşteri fonu kaybı olmadan altı aylık pilot süreci oldu.

Adayların Sıkça Gözden Kaçırdığı Noktalar

REST API istemcilerinin beklentilerinin senkron doğasını, kamu blok zinciri ağlarının asenkron, olasılıklı nihai onayı ile nasıl uzlaştırıyorsunuz, açık HTTP bağlantılarını dakikalarca tutmaksızın?

Birçok aday, blok zinciri onayı bekleyene kadar uzun süreli anketler veya engelleyici HTTP istekleri önermektedir; bu da sunucu ipliklerini tüketir ve geçit zaman aşımını tetikler. Doğru yaklaşım, CQRS deseninin Olay Kaynağı ile kombinlenmesidir. İlk yerleştirme talebi hemen 202 Kabul Edildi durumu ile döner ve benzersiz bir işlem korelasyon kimliği verir. İstemci, WebSocket veya Sunucu Tarafı Olayları (SSE) uç noktasına abonelik yapar veya Redis destekli hafif bir durum uç noktasını sorgular. Arka uç, blok zinciri onayını asenkron olarak Kafka tüketicileri aracılığıyla işler. Saga bir terminal duruma (tamamlandı veya telafi edildi) ulaştığında, durum istemciye iletilir.

Aşağı akış bankacılık API'si (JPMorgan Access veya Stripe Treasury) zaman aşımına uğrarsa, fiat borçlarının tam olarak bir kez uygulanmasını nasıl sağlarsınız; bu, fonların gerçekten hareket edip etmediği konusunda belirsizlik bırakıyor?

Adaylar genellikle yeniden denemelerin güvenli olduğunu veya yalnızca idempotentlik anahtarlarının yeterli olduğunu yanlış varsayıyor. Sağlam çözüm, PostgreSQL kullanarak bir Idempotency Ledger uygulamaktır; burada bir PENDING durum makinesi vardır. Harici API'yi çağırmadan önce, hizmet, belirleyici bir anahtar (işlem kimliği + zaman damgası kaba'nın SHA-256'sı) ile bir niyet kaydı yazar. Eğer API zaman aşımına uğrarsa, arka planda bir Saga işçi, bankanın idempotentlik sorgu uç noktasını sorgular (veya Webhook uzlaştırmasını kullanır). Yalnızca açık onay veya reddedilme durumunda durum SUCCESS veya FAILED'ye geçiş yapar.

Aynı anda hem REST API'sinden hem de gelen blok zinciri havale olaylarından aynı USDC rezervlerine erişen yüksek frekanslı arbitraj botlarında likidite parçalanmasını ve çift harcamayı nasıl önlersiniz?

Bu, veritabanı düzeyinde İyimser Kilitleme ve kritik bölümler için Dağıtık Kilitleme gerektirir. Likidite hizmeti, PostgreSQL'de versiyonlu satırlar tutar; her güncelleme, versiyonu artırır. Bir çekim imkanı denendiğinde, sistem versiyonu kontrol eder. Eğer eş zamanlı bir blok zinciri olayı satırı değiştirdiyse (versiyon uyumsuzluğu), işlem tekrar denenecektir. Acil durumda, bakiyeleri kontrol etmeden önce bir Redis Redlock alınarak ardışık erişim sağlanır. Ek olarak, likidite havuzunun çatışma oranını izleyen bir Devre Kesici (Resilience4j) kullanılır.