Wie entwirfst du eine Multi-Region-DB für HA und DR?

Question

IT Interview Practice · Accepted Answer

Repliziere die Datenbank über Regionen und wähle deine Topologie nach Bedarf: **Active-Passive** (ein Writer, ein Warm Standby, der beim Failover übernimmt) für Einfachheit und Strong Consistency, oder **Active-Active** (mehrere Writer) für niedrige Write-Latency zum Preis der Konfliktauflösung - dann wähle **Sync vs. Async Replikation**, um Durability gegen Latency abzuwägen, und definiere explizite **RPO-/RTO**-Ziele, die den Failover treiben.

```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** hat einen Primary, der Writes bearbeitet, und Standbys, die nur lesen; bei Ausfall **befördert** du einen Standby. Es ist einfach und vermeidet Write-Konflikte, aber die passive Kapazität liegt brach und der Failover hat eine Lücke. **Active-Active** lässt jede Region Writes für lokale Latency annehmen und keine Failover-Promotion - aber zwei Regionen können dieselbe Row gleichzeitig bearbeiten, also *musst* du Konflikte auflösen (Last-Write-Wins, CRDTs oder App-Level-Merge). Die meisten Teams starten Active-Passive; Active-Active ist für globale Write-Latency, die du wirklich nicht anders erreichen kannst.

## Sync vs. Async Replikation

Das ist der zentrale Durability-/Latency-Trade. **Synchron:** Der Primary wartet auf das Ack der Remote-Replica vor dem Commit - **RPO = 0** (kein Datenverlust beim Failover), aber jeder Write zahlt Cross-Region-Round-Trip-Latency (~zig ms), und ist die Replica unerreichbar, stocken Writes. **Asynchron:** Der Primary committet lokal und schickt Änderungen danach - schnelle Writes, aber ein Regionsverlust kann die letzten paar Sekunden verlieren (**RPO > 0**). Cross-Region-Sync ist oft zu langsam, daher fahren viele async und akzeptieren ein kleines RPO.

## Failover, RPO & RTO

- **RPO (Recovery Point Objective):** wie viele Daten du verlieren kannst - gesetzt durch Sync vs. Async.
- **RTO (Recovery Time Objective):** wie lange, bis du zurück bist - gesetzt dadurch, wie schnell du den Ausfall erkennst und beförderst.
- Failover = erkennen (Health Checks) → Standby befördern → Traffic umlenken (DNS/Global LB). Automatisiere es, aber schütze gegen **Split-Brain** (beide Regionen halten sich für Primary) mit einem Quorum/Fencing Token.

## Interview-Perspektive

Die Sondierung: Verstehst du, dass HA/DR ein **Trade zwischen Consistency, Latency und Datenverlust** ist - nicht "einfach eine Replica hinzufügen". Gut: Active-Passive mit einem Standby. Hervorragend: Du nennst RPO/RTO, Sync-vs-Async-Implikationen und das Split-Brain-Risiko. Falle: zu behaupten, async gebe null Datenverlust, oder anzunehmen, Failover sei sofort und verlustfrei.

## Trade-offs & Fehlermodi

- **Split-Brain:** eine Netzwerkpartition befördert zwei Primaries → divergierende Daten. Nutze Quorum, Fencing oder eine Witness-Region.
- **Failback ist schwer:** nachdem der alte Primary zurückkehrt, ist das Abgleichen divergierender Writes manuell und fehleranfällig.
- **Kosten:** echtes Multi-Region verdoppelt grob die Infra und fügt Cross-Region-Egress-Bandbreitenkosten hinzu.
- **Ungetesteter Failover scheitert:** DR, das nie geübt wird, funktioniert im echten Ausfall nicht - fahre Game-Days.

Active-Passive vs. Active-Active

Sync vs. Async Replikation

Failover, RPO & RTO

Interview-Perspektive

Trade-offs & Fehlermodi

Ähnliche Fragen