Çok Bölge Kullanılabilirliği için PostgreSQL ve CockroachDB

Gerçekte hangi problemi çözmeye çalışıyorsunuz?

"Çok-bölge kullanılabilirlik" farklı hedefler için kullanılıyor. Bu hedefleri karıştırmak ekiplerin yanlış veritabanını seçmesine yol açar.

PostgreSQL ve CockroachDB'yi karşılaştırmadan önce (1) hayatta kalmasını istediğiniz spesifik arızayı ve (2) bu arıza sırasında kullanıcıların ne deneyimlemesi gerektiğini yazın.

Çoğu ekip şu karışımı kovalıyor:

• Bir bölge kapandığında daha yüksek çalışma süresi (failover)
• Ana bölgenizden uzak kullanıcılar için daha hızlı yanıtlar (düşük gecikme)
• Verinin coğrafyayla bağlı kuralları (yerellik veya veri yerleşimi)
• Yalnızca "iyi yol" testlerinde değil, yük altında da öngörülebilir davranış

Ortak hedef basit: başka bir kıtadaki bir müşteri yine hızlı ve doğru sonuçlar almalı.

Zor olan nokta ise "hızlı" ve "doğru"nun bölgeler arası yazma yapıldığında çelişebilmesi. Daha güçlü tutarlılık genelde daha fazla bölge içi koordinasyon gerektirir ve bu da gecikmeyi artırır. Gecikmeyi azaltmak ise yakın bir kopyadan okumak veya asenkron çoğaltım kullanmak anlamına gelebilir; bu ise bayat okumalar veya sizin çözmek zorunda olduğunuz çakışma senaryoları doğurur.

Somut bir örnek: Almanya'daki bir kullanıcı gönderi adresini güncelliyor ve hemen sonra ödeme yapıyor. Ödeme, birkaç saniye geride olan ABD replikasından okunursa sipariş eski adresle işlenebilir. Bazı ürünler bunu açık bir UX ve yeniden denemelerle tolere edebilir. Diğerleri (ödeme, stok, uyumluluk) tolere edemez.

Evrensel bir en iyi seçim yoktur. Doğru cevap, hangi şeyin asla yanlış olmaması gerektiğine, hangi işlemlerin biraz daha yavaş olabileceğine ve ekibinizin günlük olarak hangi operasyonel karmaşıklığı kaldırabileceğine bağlıdır.

"Çok bölgede kullanılabilir" için iki yaklaşım

PostgreSQL ve CockroachDB'yi çok-bölge kullanım için karşılaştırırken çoğu zaman iki farklı tasarımı kıyaslıyorsunuz.

PostgreSQL'de en yaygın kurulum tek-primarydir. Yazmaların olduğu bir "ev" bölgesi vardır. Diğer bölgeler primary'den değişiklikleri kopyalayan okuma replikaları çalıştırır. Primary bölge bozulursa bir replikayı promote eder ve uygulamayı oraya yönlendirirsiniz. İyi yapıldığında bu gayet işe yarar, ancak sistem yine de bir ana yazma konumunun etrafında şekillenir ve bilinçli bir failover planı gerektirir.

CockroachDB gibi dağıtık SQL sistemleri, veriyi ve sorumluluğu baştan bölgelere yayacak şekilde tasarlanmıştır. Veri birden fazla düğüme kopyalanır ve küme yazmaların sırasına üzerinde anlaşır. Genelde belirli verileri farklı bölgelere daha yakın tutabilirken tek bir mantıksal veritabanı kullanmaya devam edebilirsiniz.

Uygulama ekibi için değişen şey SQL sözdiziminden çok beklentilerdir:

• Yazmalar: PostgreSQL yazmaları primary'ye yakınken en hızlıdır. CockroachDB yazmaları genelde birden fazla replikadan onay gerektirebilir ve bu onaylar bölgeseler arası olabilir.
• Okumalar: PostgreSQL, replikalardan yerel okumalar sunabilir (stale olma bedeliyle). CockroachDB tutarlı okumalar sunabilir, ama veri yerleşimine bağlı olarak koordinasyon maliyeti olabilir.
• Arızalar: PostgreSQL failover'ı sizin tetikleyip yönettiğiniz bir anahtar gibidir. CockroachDB bazı bölgesel arızalar boyunca çalışmaya devam edecek şekilde tasarlanmıştır, fakat bu yalnızca replikasyon ve çoğunluk kurallarına bağlıdır.

Gizli gereksinim arızalar sırasında doğruluktur. Kısa süreli bayat okumaları veya failover sırasında kısa bir yazma durmasını tolere edebiliyorsanız tek-primary PostgreSQL güçlü bir seçenek olabilir. Bir bölge kapandığında sistemin doğru ve yazılabilir kalmasını istiyorsanız, dağıtık bir veritabanının koordinasyon maliyetini kabul ediyorsunuz demektir.

Tutarlılık garantileri: neye güvenebilirsiniz

Basitçe: biri bir kaydı güncellediğinde herkes aynı gerçeği görmeli.

PostgreSQL'de güçlü tutarlılık en kolay şekilde uygulamanızın tek bir primary ile konuşmasıyla gelir. Okuma ve yazma tek yerde olur, dolayısıyla işlemler öngörülebilir davranır. Replika ekleyebilirsiniz ama o zaman biraz bayat okuma ne zaman kabul edilebilir sorusunu cevaplamalısınız.

CockroachDB ve diğer dağıtık SQL sistemlerinde de güçlü tutarlılık mümkündür, ama veriyi uzak bölgelere yaydıkça maliyet artar. Bölge-ötesi tutarlılık gerektiren yazmalar düğümler arası koordinasyon ister. Bölgeler ne kadar uzunsa, bu koordinasyon o kadar uzun sürer. Özellikle bir işlem farklı bölgelerdeki satırları etkiliyorsa daha yavaş yazmalar ve işlemler hissedilir.

Her iki sistem de serializable işlemleri destekleyebilir. Fark, işin nerede yapıldığıdır: PostgreSQL maliyetin çoğunu tek bir bölgede taşırken, dağıtık sistem bu maliyeti bölgelere yayabilir.

Takasları somut yapan birkaç soru:

• Kullanıcılar birkaç saniye bile bayat okumalar görebilir mi?
• İki bölge aynı anda bağımsız yazma kabul edebilir mi yoksa her yazı global olarak mı karara bağlanmalı?
• Aynı kaydı iki kişi aynı anda değiştirirse ne olur? Çakışmalara izin veriyor musunuz?
• Hangi işlemler her seferinde doğru olmak zorunda (ödeme, izinler) vs "sonunda kabul edilebilir" (analitik)?
• Tek bir global gerçek mi lazım yoksa bazı veriler için "yerel gerçek" kabul edilebilir mi?

Gecikme beklentileri: kullanıcılar ne hissedecek

Faydalı bir zihinsel model: mesafe süre katar, koordinasyon daha fazla süre katar. Mesafe fiziğin bir sonucudur. Koordinasyon ise veritabanının "tamam" diyebilmek için diğer düğümlerin onayını beklemesidir.

Tek bölge PostgreSQL kurulumunda çoğu iş yakın olur. Okuma ve yazma genellikle uygulamanın veritabanına bir tur-trip içinde tamamlanır. Başka bir bölgeye okuma replikası koyarsanız okumalar yerel olur ama yazmalar hala primaire gider ve replikalar geride kalır.

CockroachDB gibi dağıtık bir sistemde veri bölgelere yayıldığı için ihtiyaç duyulan veri yakındaysa bazı okumalar hızlı gelebilir. Ancak birçok yazma çoğunluk replikasından onay gerektirir. Veriler kıtalar arası çoğaltılıyorsa basit bir yazma bile çapraz bölge onayı bekleyebilir.

Ortalama gecikmeye bakmayın; p95 gecikmesine bakın (en yavaş %5). Kullanıcılar o duraklamaları fark eder. Sürekli 120 ms olan bir sayfa, günde birkaç kez 800 ms oluyorsa kullanıcı deneyimi dalgalı ve güvenilmez hissedilir.

"Hızlı" ne demek iş yükünüze bağlıdır. Yazma-ağırlıklı uygulamalar koordinasyon maliyetini daha fazla hisseder. Okuma-ağırlıklı uygulamalar yerel okumalardan iyi performans alabilir. Büyük işlemler, çok adımlı iş akışları ve aynı satır üzerinde çoklu kullanıcıların güncelleme yaptığı "hot" satırlar gecikmeyi büyütür.

PostgreSQL ve CockroachDB'yi değerlendirirken en önemli kullanıcı eylemlerinizin (kayıt, ödeme, arama, yönetici güncellemeleri) verinin nerede yaşadığına ve her işlemin kaç bölgenin onayını gerektirdiğine eşleştirin. Bu egzersiz genel kıyaslardan daha iyi bir tahmin verir.

Operasyonel takaslar: günlük neleri yönetirsiniz

Özellik listeleri, sizi gece 2'de uyandıran şey kadar önemli değildir.

PostgreSQL operasyonları tanıdık ve öngörülebilirdir. Çok-bölge genelde destekleyici parçaları da işletmenizi gerektirir: replikalar, failover araçları veya uygulama seviyesinde bölgesel cluster'lar ve yönlendirme. İş genelde planın çalıştığını kanıtlamakta (failover tatbikatları, restore testleri) olur, günlük sorgu ayarlamadan çok.

CockroachDB çok-bölge hikayesinin daha fazlasını veritabanının içine iter. Bu ekstra bileşen sayısını azaltabilir ama dağıtık bir sistemi anlamanızı şart koşar: düğüm sağlığı, replikasyon, yeniden dengeleme ve kümenin stres altındaki davranışı.

Pratikte ekipler her iki kurulumda da aynı temel işleri yaparlar:

• Güncellemeleri planlamak ve sürücüleri, izlemeyi ve otomasyonu doğrulamak
• Yedek almak ve geri yükleme testleri yapmak (sadece yedeğin varlığını kontrol etmek değil)
• Failover pratiği yapmak ve kesin runbook adımlarını yazmak
• Yavaş sorguları incelemek ve "kötü sorgu"yu bölge-ötesi gecikmeden ayırmak
• Depolama büyümesini ve uzun vadeli kompaksiyon davranışını izlemek

Arıza modları farklı hissedilir. PostgreSQL'de bir bölge kesintisi genelde kasıtlı bir failover tetikler. Bir süreliğine salt-okunur mod, yükselmiş gecikme veya azaltılmış fonksiyonellik kabul edilebilir. Dağıtık veritabanında zor senaryo genelde ağ bölünmesidir; sistem tutarlılığı korumak için bazı yazmaları reddedebilir.

Gözlemlenebilirlik de değişir. Tek bir primary'de genelde "bu sorgu neden yavaş?" diye sorarsınız. Dağıtık bir kümeye bakarken ayrıca "bu veri nereye düştü ve neden sorgu bölgeler arası geçti?" sorularını sorarsınız.

Maliyetler hem bariz hem de bariz olmayan şekillerde artar. İkinci bir bölge eklemek sadece düğüm sayısını artırmaz; izleme, olay karmaşıklığı ve ürün ekiplerine gecikme ile arıza davranışını açıklama süresini de artırır.

Dağıtık bir kurulumda şema değişiklikleri ve migrasyonlar

Şema değişikliği verinin şeklindeki her türlü güncellemedir: bir sütun eklemek, alanı yeniden adlandırmak, tip değiştirmek (int'ten string'e), indeks eklemek veya yeni bir tablo tanıtmak.

PostgreSQL'de migrasyonlar hızlı olabilir ama risk genelde kilit süresi ve yazmaların bloke olmasıdır. Bazı değişiklikler tüm tabloyu yeniden yazar veya beklenenden uzun süren kilitler tutar; bu da yoğun trafikte normal bir dağıtımı olaya çevirebilir.

Dağıtık bir veritabanında risk kayar. Çevrim içi şema değişiklikleri desteklense bile değişiklik tüm düğümler arasında anlaşma ve bölgeler arası çoğaltma gerektirir. "Basit" değişiklikler daha uzun sürebilir ve doğrulaması daha uzun zaman alabilir. Deploy'u bitirseniz bile bölgelerin yakalanmasını, hotspot'ları ve sorgu planı sürprizlerini izlemekle vakit geçirebilirsiniz.

Migrasyonları sıkıcı kılmayan birkaç alışkanlık:

• Önce ekleyici değişiklikleri tercih edin (yeni sütun, yeni tablo). Sonra okumaları/yazmaları değiştirin. Eski alanları daha sonra kaldırın.
• Her migrasyonu hızlıca geri alabilecek kadar küçük tutun.
• Mümkünse tip değiştirmeyi yerinde yapmaktan kaçının. Yeni bir sütuna backfill yapın.
• İndeksleri hızlı bir değişiklik değil bir özellik dağıtımı gibi ele alın.
• Migrasyonları gerçekçi veri boyutlarıyla, boş test veritabanlarıyla değil pratik senaryolarla prova edin.

Örnek: AB kullanıcıları için preferred_language ekliyorsunuz. Önce sütunu ekleyin, bir sürüm boyunca hem eski hem yeni alanı yazın, sonra UI'yi yeni alanı okumaya güncelleyin ve en son temizliği yapın. Çok-bölge kurulumlarda aşamalı dağıtımlar bölgelerin farklı hızlarda yakalaması durumunda sürprizleri azaltır.

Erken dağıtıma geçmenin gerçek maliyeti

PostgreSQL ile CockroachDB arasında seçim yapmak sadece veritabanı kararı değildir. Bu seçim ne kadar hızlı ürün çıkarabileceğinizi, prodüksiyonda kaç sürprizle karşılaşacağınızı ve ekibinizin sistemi stabil tutmak için harcadığı zamanı değiştirir.

Hedeflerinizi tek bir primary bölgeyle karşılayabiliyorsanız, basit kalmak genelde erken aşamada kazanır. Daha az hareketli parça, daha net arızalar ve daha hızlı hata ayıklama elde edersiniz. İşe alım da kolaydır çünkü derin PostgreSQL deneyimi yaygındır ve yerel geliştirme ile CI daha basittir.

Ekipler genellikle önce merkezi kalmayı tercih eder çünkü daha hızlı iterasyon, daha basit geri dönüşler ve daha öngörülebilir performans sağlar. On-call da daha kolaydır çünkü sistemde daha az hareketli parça vardır.

Erken dağıtıma geçmek yine de doğru olabilir; örneğin bölgeler arası katı çalışma süresi hedefleriniz, yasal veri yerleşimi gereksinimleriniz veya gecikmenin doğrudan gelire etki ettiği küresel kullanıcı tabanınız varsa.

Karmaşıklık vergisi küçük yollarla ortaya çıkar ama birikir: Özellik geliştirmek daha uzun sürer çünkü çok-bölge davranışını düşünmek gerekir, testler daha fazla arıza modunu kapsamalıdır ve olayların kök nedenleri zamanlama, çoğaltma veya konsensüs kaynaklı olabilir; basit şema değişiklikleri bile daha dikkat ister.

Pratik bir başparmak kuralı: önce talebi doğrulayın, sonra acı ölçülebilir olduğunda dağıtın. Ortak tetikleyiciler bir bölgede SLO'ların kaçırılması, gecikme nedeniyle kullanıcı kaybı veya anlaşmaları engelleyen uyumluluk gereksinimleridir.

AppMaster gibi bir araçla inşa ediyorsanız, dağıtımı basit tutarak iş akışlarını ve veri modellerini rafine etmek, sonra ürün ve trafik kanıtlandığında çok-bölge planına geçmek daha az maliyetli olabilir.

Aralarından seçim yapmak için adım adım yol

"Çok-bölge" kavramını birkaç sayı ve bazı kullanıcı akışlarına indirgediğinizde daha netleşir.

Adım adım

1. RPO ve RTO'yu düz metinle yazın. Örnek: "Bir bölge ölürse en fazla 1 dakika veri kaybedebiliriz (RPO) ve 15 dakika içinde toparlanmış olmalıyız (RTO)." Gerçekleşmiş yazmaları kaybetmeyi tolere edemiyorsanız bunu açıkça belirtin.
2. Kullanıcıların nerede olduğunu haritalayın ve yazma açısından kritik eylemleri işaretleyin. Bölgelerinizi ve en önemli eylemleri listeleyin: kayıt, ödeme, şifre sıfırlama, yorum gönderme, bir beslemeyi görüntüleme. Tüm yazmalar eşit önemde değildir.
3. Her özellik için tutarlılık ihtiyacını belirleyin. Ödemeler, stok ve hesap bakiyeleri genelde sıkı doğruluk ister. Beslemeler, analitik ve "son görülme" gibi veriler hafif gecikmeyi kabul edebilir.
4. Gecikme bütçesi belirleyin ve hedef bölgeden test edin. "Yeterince hızlı"nın ne anlama geldiğini karar verin (örneğin ana eylemler için 200–400 ms) ve ilgilendiğiniz bölgelerden round-trip zamanını ölçün.
5. Ekibinizin destekleyebileceği bir işletme modelini seçin. On-call süresine, veritabanı becerilerine ve karmaşıklık toleransına dürüst olun.

Kısa bir örnek

Kullanıcıların çoğu ABD'de ve küçük bir kısmı AB'deyse, yazmaları tek bir primary bölgede tutup kurtarma hedeflerini sıkılaştırmak ve kritik olmayan ekranlar için AB okuma optimizasyonu eklemek mantıklı olabilir. Eğer AB'de yazma-ağırlıklı akışlar daha iyi UX gerektiriyorsa, UI'nın tepki vermesi için AB servis katmanı veya kuyruk kullanmayı düşünün. Çok-bölge doğruluğu temel tablolar (hesaplar, faturalama, izinler) için gerekli hale geldiğinde veritabanı seçimini yeniden gözden geçirin.

Örnek senaryo: Aynı üründe ABD ve AB müşterileri

Bir B2B SaaS hayal edin: bir hesaptaki ekip üyeleri New York ve Berlin'de. Herkes aynı biletleri, faturaları ve kullanım limitlerini görüyor. Faturalama ortak olduğundan bir ödeme olayı tüm hesap için hemen erişimi etkilemeli.

PostgreSQL ile yaygın düzen: ABD'de bir primary veritabanı ve AB'de raporlama ile kritik olmayan ekranlar için okuma replikaları. ABD kullanıcıları hızlı okuma ve yazma alır. AB kullanıcıları yerel okumalar alabilir ama anlık doğruluk gerektiren istekler genelde ABD primaire gitmelidir. Replikadan okunduğunda gecikme varsa finans yöneticisi Berlin'de bir faturayı ödeyip yenilediğinde bir süre "geçmiş vade" görebilir.

CockroachDB gibi çok-bölgeli dağıtık bir veritabanıyla veriyi her iki bölgeye daha yakın yerleştirip tek bir mantıksal veritabanı tutabilirsiniz. Ama takas şudur: birçok yazma ve bazı okumalar tutarlı kalmak için bölgeler arası koordinasyon yapmak zorunda olur. Bu ekstra çapraz bölge turu paylaşılan hesap ayarları ve faturalama gibi işlemlerin normal yolunun bir parçası hâline gelir.

Sık işe yarayan bir aşamalı plan:

• Önce tek bir bölge ve tek PostgreSQL primary ile başlayın; kullanıcıların ve yazmaların gerçekten nerede olduğunu ölçün.
• Raporlama ve kritik olmayan ekranlar için AB okuma replikaları ekleyin.
• AB yazma-ağırlıklı akışlar daha iyi bir UX gerektiriyorsa, UI'nın yanıt vermesi için AB servis katmanı veya kuyruk uygulayın.
• Çok-bölge doğruluğu temel tablolar için gerekli hale geldiğinde veritabanı seçimini yeniden değerlendirin.

AppMaster ile inşa ediyorsanız, görsel iş süreçlerinde mantığı tutmak daha sonra dağıtım bölgelerini veya veritabanı stratejisini değiştirmeyi kolaylaştırabilir.

Ekiplerin yaptığı yaygın hatalar

En büyük hata, "çok-bölge"nin otomatik olarak herkese hızlı olduğu varsayımıdır. Dağıtık bir veritabanı fiziği yenecek şekilde sihir yapmaz: bir işlem iki uzak yerde onay gerektiriyorsa round-trip süresi her yazmada ortaya çıkar.

Bir diğer tuzak da doğruluk beklentilerini açıkça kabul etmemektir. Ekipler bakiye, stok ve izinler için sıkı doğruluk ister ama uygulamanın diğer kısımlarını "yeterince yakın" varsayar. Sonuçta kullanıcı bir ekranda bir değeri, diğer ekranda başka bir değeri görebilir.

Dikkat edilmesi gereken kalıplar:

• Çapraz bölge onayı gerektiren tüm yazmaların yerel hissetmesini beklemek
• Sonunda tutarlı modeli sadece UI detayı olarak ele almak ve bunun iş kurallarını bozduğunu görmek (iade, kota, erişim)
• Operasyonel gerçekleri ilk olaydan sonra öğrenmek (yedekler, yükseltmeler, düğüm sağlığı, bölge arızaları)
• Günlüklerde ve veride bölgeler arası dağılım olduğunda yavaş işlemleri debug etmenin beklenenden uzun sürmesini hafife almak
• İlk kararı kalıcı bir seçimmiş gibi ele almak yerine evrim yolunu planlamamak

Migrasyonlar ekstra dikkat ister çünkü ürün genelde en hızlı büyüdüğü anda değişiklikler yapılır. Tek bir düğümde kolay olan bir şema değişikliği, birçok düğüm ve bölge üzerinde tutarlılığı korumaya çalışırken riskli hale gelebilir.

İlk veritabanı seçimini bir adım olarak görün, kaderiniz olarak değil. AppMaster ile prototipler hızlıca yapılabilir, gecikme ve arıza davranışı üretime benzer testlerde doğrulanabilir ve çok-bölgeye geçiş ancak ihtiyaç kesinleşince yapılır.

Taahhüt etmeden önce kısa kontrol listesi

Yön seçmeden önce "iyi"nin ne olduğunu tanımlayın. Çok-bölge kurulumları gerçek problemleri çözer ama aynı zamanda gecikme, tutarlılık ve operasyonlar hakkında sürekli kararlar almanızı gerektirir.

Kısa ve spesifik kontrol listesi:

• En önemli 3 kullanıcı aksiyonunuzu belirleyin (örnek: giriş, ödeme, paylaşılan bir kaydı güncelleme) ve bu kullanıcıların nerede olduğunu not edin.
• Bölgeler arası hangi işlemlerin güçlü tutarlılık gerektirdiğini, hangilerinin gecikmeyi tolere edebileceğini kararlaştırın.
• Arıza senaryonuzu düz metinle yazın: "Bölge X 1 saat down olduğunda bölge Y'deki kullanıcılar A ve B işlemlerini yapabilir ama C'yi yapamaz." gibi.
• Yedekleme, geri yükleme testi, yükseltmeler ve izleme için sahiplik atayın.
• Aşamalı dağıtımlarla uygulamla uyumlu tutacak bir şema değişikliği planı taslağı oluşturun.

AppMaster gibi bir no-code platformu kullanıyorsanız bu kontrol listesini build notlarınıza erken koymak veri modelinizi, iş mantığınızı ve dağıtım adımlarınızı gereksinimler değiştikçe hizalar.

Sonraki adımlar: varsayımlarınızı test edin ve bir yol seçin

Çoğu ekip ilk gün dağıtık bir veritabanına ihtiyaç duymaz. Onların ihtiyacı öngörülebilir davranış, basit operasyonlar ve büyüme için net bir yol haritasıdır.

Bu karar genelde tek bir soruya indirgenir: temel iş akışları için birden fazla bölgede doğru ve aktif yazmalara gerçekten ihtiyaç var mı?

• Yazmaları tek bir primary bölgede tutup replikalar, cache'ler veya salt-okunur kopyalar kullanabiliyorsanız PostgreSQL genelde iyi bir seçimdir.
• Eğer çekirdek iş akışları için çok-bölgede yazmalar ve güçlü tutarlılık gerçekten gerekiyorsa, dağıtık SQL uyacaktır; ancak daha yüksek temel gecikme ve daha fazla operasyonel karmaşıklığı kabul etmeniz gerekir.

Tercihinizi sınamak için odaklanmış bir doğrulama yapın.

Küçük bir doğrulama planı (1-2 gün)

• İlgili her bölgeden p95 gecikmesini ölçün (okuma ve yazma).
• Bir arıza modu simüle edin (bir düğümü öldürün, bir bölgeyi bloke edin veya bölgeler arası trafiği devre dışı bırakın) ve neyin bozulduğunu kaydedin.
• 2-3 kritik işlemi uçtan uca çalıştırın (kayıt, ödeme, profil güncelleme) ve yeniden denemeleri, zaman aşımlarını ve kullanıcıya görünen hataları izleyin.
• Sık yapmayı beklediğiniz bir şema değişikliğini deneyin (sütun ekleme, indeks ekleme). Süresini ölçün ve neleri engellediğini not edin.

Ardından veri sahipliğini yazın. Hangi bölge bir müşteri kaydının "sahibi"? Hangi tablolar güçlü tutarlılık gerektirir, hangileri sonradan kabul edilebilir (örneğin analitik olayları)? Ayrıca taşınmayı tetikleyecek durumları, nasıl backfill yapacağınızı ve nasıl geri alacağınızı kararlaştırın.

Yaygın yol şudur: PostgreSQL ile başlayın, şemayı temiz tutun (meydana net birincil anahtarlar, daha az çapraz tablo yazma hotspot'ları) ve bölgeye özgü veriyi daha sonra ayırmayı kolaylaştırın.

AppMaster kullanıyorsanız Data Designer'da bir PostgreSQL şemasını modelleyebilir ve üretime hazır uygulamalar oluşturup gerçekten çok-bölge yazmalara ihtiyaç olup olmadığını doğrulayabilirsiniz. AppMaster on appmaster.io, karmaşık çok-bölge mimarisine erken bağlanmadan tüm yığıntıyı (backend, web, mobil) prototiplemek için sezgisel bir yol sağlar.