Come progetti un DB multi-region per HA e DR?

Question

IT Interview Practice · Accepted Answer

Replica il database tra region e scegli la topologia in base al bisogno: **active-passive** (un writer, uno warm standby che subentra al failover) per semplicità e consistenza forte, o **active-active** (più writer) per bassa latenza di scrittura al costo della risoluzione dei conflitti — poi scegli **replica sync vs async** per bilanciare durabilità e latenza, e definisci target **RPO/RTO** espliciti che guidano il 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

L'**active-passive** ha un primary che gestisce le scritture e standby che leggono soltanto; al guasto **promuovi** uno standby. È semplice ed evita i conflitti di scrittura, ma la capacità passiva resta inattiva e il failover ha un gap. L'**active-active** lascia che ogni region accetti scritture per latenza locale e nessuna promozione al failover — ma due region possono modificare la stessa riga concorrentemente, quindi *devi* risolvere i conflitti (last-write-wins, CRDT, o merge a livello applicativo). La maggior parte dei team parte da active-passive; l'active-active è per una latenza di scrittura globale che genuinamente non puoi soddisfare altrimenti.

## Replica sync vs async

Questo è il compromesso centrale durabilità/latenza. **Sincrona:** il primary attende l'ack della replica remota prima di committare — **RPO = 0** (nessuna perdita di dati al failover) ma ogni scrittura paga la latenza del round-trip cross-region (~decine di ms), e se la replica è irraggiungibile, le scritture si bloccano. **Asincrona:** il primary committa localmente e invia i cambiamenti dopo — scritture veloci, ma una perdita di region può perdere gli ultimi secondi (**RPO > 0**). La sync cross-region è spesso troppo lenta, quindi molti usano async e accettano un piccolo RPO.

## Failover, RPO e RTO

- **RPO (Recovery Point Objective):** quanti dati puoi perdere — determinato da sync vs async.
- **RTO (Recovery Time Objective):** quanto ci mette a tornare operativo — determinato da quanto velocemente rilevi il guasto e promuovi.
- Failover = rileva (health check) → promuovi lo standby → reindirizza il traffico (DNS/global LB). Automatizzalo, ma proteggiti dallo **split-brain** (entrambe le region si credono primary) con un token di quorum/fencing.

## Prospettiva del colloquio

Il sondaggio: comprendi che HA/DR è un **compromesso tra consistenza, latenza e perdita di dati** — non "basta aggiungere una replica". Buono: active-passive con uno standby. Eccellente: dichiari RPO/RTO, le implicazioni sync-vs-async, e il rischio di split-brain. Trappola: sostenere che l'async dia zero perdita di dati, o assumere che il failover sia istantaneo e senza perdite.

## Compromessi e modalità di guasto

- **Split-brain:** una partizione di rete promuove due primary → dati divergenti. Usa quorum, fencing, o una witness region.
- **Il failback è difficile:** dopo il ritorno del vecchio primary, riconciliare le scritture divergenti è manuale e soggetto a errori.
- **Costo:** un vero multi-region raddoppia grosso modo l'infra e aggiunge fatture di banda di egress cross-region.
- **Un failover non testato fallisce:** un DR mai provato non funzionerà nell'interruzione reale — fai game-day.

Active-passive vs active-active

Replica sync vs async

Failover, RPO e RTO

Prospettiva del colloquio

Compromessi e modalità di guasto

Domande correlate