Comment concevez-vous une DB multi-région pour la HA et la DR ?

Question

IT Interview Practice · Accepted Answer

Répliquez la base de données à travers les régions et choisissez votre topologie selon le besoin : **active-passive** (un seul writer, un standby chaud qui prend le relais au failover) pour la simplicité et la forte cohérence, ou **active-active** (plusieurs writers) pour une faible latence d'écriture au prix de la résolution de conflits — puis choisissez la **réplication sync vs async** pour arbitrer entre durabilité et latence, et définissez des cibles **RPO/RTO** explicites pilotant le 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** a un seul primary gérant les écritures et des standbys qui ne font que lire ; en cas de panne vous **promouvez** un standby. C'est simple et évite les conflits d'écriture, mais la capacité passive reste inactive et le failover a un écart. **Active-active** laisse chaque région accepter les écritures pour la latence locale et sans promotion de failover — mais deux régions peuvent éditer la même ligne simultanément, donc vous *devez* résoudre les conflits (last-write-wins, CRDTs, ou merge applicatif). La plupart des équipes commencent en active-passive ; l'active-active est pour une latence d'écriture globale que vous ne pouvez vraiment pas atteindre autrement.

## Réplication sync vs async

C'est le compromis central durabilité/latence. **Synchrone :** le primary attend l'acquittement du réplica distant avant de commiter — **RPO = 0** (aucune perte de données au failover) mais chaque écriture paie la latence d'aller-retour cross-région (~dizaines de ms), et si le réplica est injoignable, les écritures se bloquent. **Asynchrone :** le primary commite localement et expédie les changements ensuite — écritures rapides, mais une perte de région peut perdre les dernières secondes (**RPO > 0**). Le sync cross-région est souvent trop lent, donc beaucoup font de l'async et acceptent un petit RPO.

## Failover, RPO & RTO

- **RPO (Recovery Point Objective) :** combien de données vous pouvez perdre — fixé par sync vs async.
- **RTO (Recovery Time Objective) :** combien de temps avant d'être de retour — fixé par la vitesse de détection de panne et de promotion.
- Failover = détecter (health checks) → promouvoir le standby → rediriger le trafic (DNS/global LB). Automatisez-le, mais protégez-vous du **split-brain** (les deux régions se croient primary) avec un quorum/fencing token.

## Perspective d'entretien

Le test : comprenez-vous que la HA/DR est un **compromis entre cohérence, latence et perte de données** — pas « juste ajouter un réplica ». Bien : active-passive avec un standby. Excellent : vous énoncez le RPO/RTO, les implications sync-vs-async, et le risque de split-brain. Piège : prétendre que l'async donne zéro perte de données, ou supposer que le failover est instantané et sans perte.

## Compromis et pannes

- **Split-brain :** une partition réseau promeut deux primaries → données divergentes. Utilisez un quorum, du fencing, ou une région témoin.
- **Le failback est difficile :** après le retour de l'ancien primary, réconcilier les écritures divergentes est manuel et sujet aux erreurs.
- **Coût :** un vrai multi-région double environ l'infra et ajoute des factures de bande passante egress cross-région.
- **Un failover non testé échoue :** une DR jamais exercée ne fonctionnera pas lors de la vraie panne — faites des game-days.

Active-passive vs active-active

Réplication sync vs async

Failover, RPO & RTO

Perspective d'entretien

Compromis et pannes

Questions connexes