Bagaimana Anda merancang DB multi-region untuk HA dan DR?

Question

IT Interview Practice · Accepted Answer

Replikasi database antar-region dan pilih topologi sesuai kebutuhan: **active-passive** (satu writer, warm standby yang mengambil alih saat failover) untuk kesederhanaan dan konsistensi kuat, atau **active-active** (banyak writer) untuk latensi write rendah dengan biaya resolusi konflik — lalu pilih **sync vs async replication** untuk menukar durability dengan latensi, dan definisikan target **RPO/RTO** eksplisit yang menggerakkan failover.

```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** punya satu primary yang menangani write dan standby yang hanya membaca; saat gagal Anda **mempromosikan** standby. Sederhana dan menghindari konflik write, tetapi kapasitas pasif menganggur dan failover memiliki celah. **Active-active** membiarkan setiap region menerima write untuk latensi lokal dan tanpa promosi failover — tetapi dua region bisa mengedit baris yang sama bersamaan, jadi Anda *harus* menyelesaikan konflik (last-write-wins, CRDT, atau merge level-app). Sebagian besar tim mulai active-passive; active-active untuk latensi write global yang benar-benar tak bisa Anda penuhi dengan cara lain.

## Sync vs async replication

Ini trade-off durability/latensi inti. **Sinkron:** primary menunggu replica remote meng-ack sebelum commit — **RPO = 0** (tanpa kehilangan data saat failover) tetapi setiap write membayar round-trip lintas-region (~puluhan ms), dan jika replica tak terjangkau, write terhenti. **Asinkron:** primary commit lokal dan mengirim perubahan setelahnya — write cepat, tetapi kehilangan region bisa kehilangan beberapa detik terakhir (**RPO > 0**). Sync lintas-region sering terlalu lambat, jadi banyak yang menjalankan async dan menerima RPO kecil.

## Failover, RPO & RTO

- **RPO (Recovery Point Objective):** seberapa banyak data yang bisa Anda hilangkan — ditentukan oleh sync vs async.
- **RTO (Recovery Time Objective):** seberapa lama sampai Anda kembali — ditentukan oleh seberapa cepat Anda mendeteksi kegagalan dan mempromosikan.
- Failover = deteksi (health check) → promosikan standby → arahkan ulang trafik (DNS/global LB). Otomasikan, tetapi jaga terhadap **split-brain** (kedua region mengira dirinya primary) dengan quorum/fencing token.

## Perspektif wawancara

Yang diselidiki: apakah Anda memahami HA/DR adalah **trade-off antara consistency, latency, dan kehilangan data** — bukan "tambah saja replica". Baik: active-passive dengan standby. Hebat: Anda menyatakan RPO/RTO, implikasi sync-vs-async, dan risiko split-brain. Jebakan: mengklaim async memberi nol kehilangan data, atau mengasumsikan failover instan dan tanpa kehilangan.

## Trade-off & mode kegagalan

- **Split-brain:** partisi jaringan mempromosikan dua primary → data berdivergensi. Gunakan quorum, fencing, atau witness region.
- **Failback itu sulit:** setelah primary lama kembali, merekonsiliasi write yang berdivergensi bersifat manual dan rawan galat.
- **Biaya:** multi-region sejati kira-kira menggandakan infra dan menambah tagihan bandwidth egress lintas-region.
- **Failover tak teruji gagal:** DR yang tak pernah dilatih tidak akan bekerja pada padam nyata — jalankan game-day.

Active-passive vs active-active

Sync vs async replication

Failover, RPO & RTO

Perspektif wawancara

Trade-off & mode kegagalan

Pertanyaan terkait