Sorunun Tarihi
Küresel olarak genişleyen işletmeler, GDPR ve CCPA gibi katı veri ikamet yasalarıyla karşılaşmaktadır. Geleneksel monolitik veritabanları verileri tek bir bölgede merkezi hale getirerek egemenlik ihlali veya yüksek gecikmeye neden olur. İlk dağıtık sistemler, aktif-pasif çoğaltma kullanıyordu, ancak bu, tek hatalı noktalar oluşturuyor ve yazma gecikmesi sorunlarına yol açıyordu. Modern mimariler, AB, ABD ve APAC'ta kullanıcıların, veri yerellik kısıtlarını dikkate alarak yerel olarak yazmalarına olanak tanıyan çok aktif bölgeleri desteklemelidir.
Sorun
Temel zorluk, CAP teoremi ikilemlerindedir. Düşük gecikme ve parçalanma toleransı ile birlikte güçlü tutarlılık elde edemezsiniz. Ayrıca, bölgeleri kapsayan yabancı anahtar ilişkileri, verilerin sınırları geçemediği durumlarda imkansız hale gelir. Sınır ötesi işlemler, PII'nin koordinasyon sırasında sızma riski taşırsa uyumluluğu ihlal edebilir. 100 ms altı okuma sağlamak için önbellekleme gereklidir, ancak egemen sınırlar arasındaki önbellek geçersiz kılma karmaşıktır.
Çözüm
Veri tabanı yerel coğrafi bölümlenmesi (örneğin, CockroachDB veya Google Cloud Spanner) kullanan Hücre Tabanlı Mimari uygulayın. Tablo bölümlerini region sütununa göre ayırarak PII'nin fiziksel hücresini asla terk etmemesini sağlayın. Yalnızca hassas olmayan meta verileri küresel olarak çoğaltmak için Apache Kafka aracılığıyla Değişiklik Veri Yakalama (CDC) kullanın. Sınır ötesi işlemler için, dağıtılmış kilitlerden kaçınmak adına yerel telafi işlemleri ile birlikte Saga modelini uygulayın. Cache-Aside modeli ile okunması yoğun iş yükleri için Redis kümelerini kenar noktalarında dağıtın ve sınır ötesi önbellek koordinasyonunu önlemek için TTL tabanlı geçersiz kılmayı kullanın.
Kontekst
Küresel bir ödeme işlemcisi, Almanya ve Singapur'da hizmet vermeye başlarken ABD veri merkezini de korumak zorundaydı. Düzenleyici gereklilikler, AB kullanıcılarının işlem geçmişlerinin fiziksel olarak Frankfurt'ta kalmasını zorunlu kıldı, APAC verilerinin ise Singapur'da kalmasını sağladı. Ancak, sınır ötesi transferlerde, bir ABD hesabından fon çekilip aynı mantıksal işlem içinde bir AB hesabına kredi verilmesi gerekiyordu ve tüm bunlar 100 ms altında bakiye sorguları sağlarken yapılmalıydı.
Çözüm 1: Bölgesel Okuma Replika ile Merkezileştirilmiş Veri Tabanı
Bu yaklaşım, ana veritabanını ABD-Doğu bölgesinde, AB ve APAC'ta okuma replikaları ile barındırır, basit bir tutarlılık modeli ve karmaşık senkronizasyon olmadan düz bir ACID garantisi sunar. Ancak bu, veri egemenliği yasalarını ihlal eder çünkü yazma trafiği ABD-Doğu'ya yönlendirilir, bu da AB PII'nin ABD topraklarında kalmasına neden olabilir ve Singapur'dan gelen yazmalar 200 ms'nin üzerinde gecikmeye neden olur, bu da kullanıcı deneyimi gereksinimlerini karşılamaz. Mimari ayrıca, bölgesel özerklik gerektiren küresel bir ödeme platformu için kabul edilemez hale gelen ABD-Doğu'da tek bir hata noktası oluşturur.
Çözüm 2: Gece ETL ile Tam İzole Bölgesel Silolar
Bu tasarım, her bölgede bağımsız PostgreSQL kümeleri çalıştırır ve uluslararası transferleri gece bakım süreleri sırasında işleyerek mükemmel uyum izolasyonu ve basit bölgesel özerklik sağlar. Ancak, bu yaklaşım gerçek zamanlı uluslararası ödemeleri desteklemez, kötü bir kullanıcı deneyimi oluşturur ve toplu işleme sırasında uzlaşma hatalarını düzeltmeyi zorlaştırır. Ayrıca, mimari, önemli bir gecikme olmadan küresel hesap bakiyesi toplamalarını destekleyemez, bu da onu modern bir fintech platformu için uygun hale getirmez.
Çözüm 3: Saga Orkestrasyonu ile Coğrafi Bölümlenmiş Veritabanı
Bu strateji, kullanıcı ev sahibi bölgelerine göre partition_key eşleme kullanarak coğrafi bölümlenmiş tablolar ile CockroachDB dağıtır, yerel işlemler olarak sınır ötesi transferleri yönetmek için bir Temporal iş akışı uygular. Bu tasarım, bölümlendirme kısıtları ile yerel veri ikametini zorlar ve bölgesel düğümlere sabitlenmiş kiracıların yanı sıra 50 ms altı yerel okumalar elde eder, ancak dağınık SQL uzmanlığı gerektiren operasyonel karmaşıklığı da beraberinde getirir. Çözüm, sınır ötesi meta veriler için Kafka CDC akışları ile nihai tutarlılığı yönetir ve TTL tabanlı bekleme durumu görünürlüğü ile saga yürütülmesi sırasında geçici tutarsızlıkları işler.
Seçilen Yaklaşım
Ekip, Çözüm 3'ü seçti çünkü bu ikisi de uyum ve gecikme kısıtlarını, işlem anlamsalını feda etmeden veya yıkıcı veri göçleri gerektirmeden tatmin ettiği için eşsizdi. CockroachDB REGIONAL BY ROW tablolarını Frankfurt düğümlerine sabitleyerek yapılandırdılar, kenar noktalarında 5 saniye TTL'ye sahip Redis Kümesi dağıttılar ve başarısızlık durumunda otomatik telafi işlemleri ile sınır ötesi transferleri düzenlemek için Temporal sagalarını uyguladılar.
Sonuç
Sistem, sıfır sınır ötesi PII sızması ile 50.000 günlük sınır ötesi işlemi gerçekleştirerek %99 okuma gecikmesi 45 ms olan GDPR denetimlerini geçti. Müşteri destek ekipleri, bölgesel kesintiler sırasında geçici tutarsızlıkları çözmek için bekleyen saga durumlarını API uç noktaları aracılığıyla sorgulayabiliyordu. Mimari, uygulama değişikliklerine gerek kalmadan CockroachDB kümesine yeni hücreler ekleyerek yeni pazarlara genişlemeyi artık destekliyor.