HA ve DR için multi-region bir DB'yi nasıl tasarlarsınız?

Question

IT Interview Practice · Accepted Answer

Veritabanını region'lar arasında replicate edin ve topolojinizi ihtiyaca göre seçin: basitlik ve strong consistency için **active-passive** (bir writer, failover'da devralan sıcak bir standby) veya conflict resolution maliyeti karşılığında düşük write latency için **active-active** (birden çok writer) — sonra durability'yi latency'ye karşı takas etmek için **sync vs async replication** seçin ve failover'ı yönlendiren açık **RPO/RTO** hedefleri tanımlayın.

```text
        ┌──────────── Region A (primary) ────────────┐
writes ─▶ app ─▶ DB primary ──┐
                              │ replication
        ┌─────────────────────┼── async (RPO>0) ─────┐
        │                     └── sync (RPO=0, slow)  │
        ▼                                             ▼
   Region B standby                            (failover promotes standby)
        │
   health check ──▶ on primary loss: promote + repoint DNS/traffic
```

## Active-passive vs active-active

**Active-passive**, yazmaları işleyen bir primary ve yalnızca okuyan standby'lara sahiptir; hata durumunda bir standby'ı **terfi** edersiniz. Basittir ve write conflict'lerinden kaçınır, ancak passive kapasite boşta durur ve failover'ın bir boşluğu vardır. **Active-active**, her region'ın local latency için yazma kabul etmesine izin verir ve failover terfisi yoktur — ancak iki region aynı satırı eşzamanlı düzenleyebilir, bu yüzden conflict'leri çözmeniz *gerekir* (last-write-wins, CRDT'ler veya app-level merge). Çoğu takım active-passive ile başlar; active-active, başka türlü karşılayamayacağınız global write latency içindir.

## Sync vs async replication

Bu çekirdek durability/latency ödünleşimidir. **Synchronous:** primary, commit etmeden önce remote replica'nın acknowledge etmesini bekler — **RPO = 0** (failover'da veri kaybı yok) ama her yazma cross-region round-trip latency öder (~onlarca ms) ve replica ulaşılamazsa yazmalar durur. **Asynchronous:** primary local commit eder ve değişiklikleri sonra ship eder — hızlı yazmalar, ancak bir region kaybı son birkaç saniyeyi kaybedebilir (**RPO > 0**). Cross-region sync sık sık çok yavaştır, bu yüzden birçoğu async çalıştırır ve küçük bir RPO kabul eder.

## Failover, RPO & RTO

- **RPO (Recovery Point Objective):** kaybedebileceğiniz veri miktarı — sync vs async ile belirlenir.
- **RTO (Recovery Time Objective):** geri dönene kadar ne kadar süre — hatayı ne kadar hızlı tespit edip terfi ettiğinizle belirlenir.
- Failover = tespit (health check'ler) → standby'ı terfi et → trafiği yeniden yönlendir (DNS/global LB). Otomatikleştirin ama bir quorum/fencing token ile **split-brain**'e (her iki region da primary olduğunu düşünür) karşı korunun.

## Mülakat perspektifi

Yoklama: HA/DR'nin "sadece bir replica ekle" değil, **consistency, latency ve veri kaybı arasında bir takas** olduğunu anlayıp anlamadığınız. İyi: bir standby'lı active-passive. Harika: RPO/RTO'yu, sync-vs-async etkilerini ve split-brain riskini belirtirsiniz. Tuzak: async'in sıfır veri kaybı verdiğini iddia etmek veya failover'ın anında ve kayıpsız olduğunu varsaymak.

## Ödünleşimler & hata modları

- **Split-brain:** bir network partition iki primary terfi ettirir → ayrışan veri. Quorum, fencing veya bir witness region kullanın.
- **Failback zordur:** eski primary döndükten sonra, ayrışan yazmaları mutabakat yapmak manuel ve hataya açıktır.
- **Maliyet:** gerçek multi-region infra'yı kabaca ikiye katlar ve cross-region egress bandwidth faturaları ekler.
- **Test edilmemiş failover başarısız olur:** asla tatbikat yapılmayan DR, gerçek kesintide çalışmaz — game-day'ler yapın.

Active-passive vs active-active

Sync vs async replication

Failover, RPO & RTO

Mülakat perspektifi

Ödünleşimler & hata modları

İlgili sorular