Πώς σχεδιάζετε μια multi-region βάση για HA και DR;

Question

IT Interview Practice · Accepted Answer

Κάντε replicate τη βάση σε περιοχές και επιλέξτε την τοπολογία σας κατά ανάγκη: **active-passive** (ένας writer, ένα warm standby που αναλαμβάνει στο failover) για απλότητα και strong consistency, ή **active-active** (πολλαπλοί writers) για χαμηλό write latency με κόστος το conflict resolution — μετά επιλέξτε **sync vs async replication** για να ανταλλάξετε durability έναντι latency, και ορίστε ρητά **RPO/RTO** targets που οδηγούν το 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** έχει ένα primary που χειρίζεται writes και standbys που μόνο διαβάζουν· σε αποτυχία **προάγετε** ένα standby. Είναι απλό και αποφεύγει write conflicts, αλλά η passive capacity κάθεται αδρανής και το failover έχει ένα κενό. Το **active-active** αφήνει κάθε περιοχή να δέχεται writes για local latency και καμία failover promotion — αλλά δύο περιοχές μπορούν να επεξεργαστούν την ίδια row ταυτόχρονα, οπότε *πρέπει* να λύσετε τα conflicts (last-write-wins, CRDTs, ή app-level merge). Οι περισσότερες ομάδες ξεκινάνε active-passive· το active-active είναι για global write latency που πραγματικά δεν μπορείτε αλλιώς να πετύχετε.

## Sync vs async replication

Αυτό είναι το βασικό durability/latency trade. **Synchronous:** το primary περιμένει το remote replica να κάνει acknowledge πριν το commit — **RPO = 0** (καμία απώλεια δεδομένων στο failover) αλλά κάθε write πληρώνει cross-region round-trip latency (~δεκάδες ms), και αν το replica είναι μη προσβάσιμο, τα writes κολλάνε. **Asynchronous:** το primary κάνει commit τοπικά και στέλνει αλλαγές μετά — γρήγορα writes, αλλά μια απώλεια περιοχής μπορεί να χάσει τα τελευταία λίγα δευτερόλεπτα (**RPO > 0**). Το cross-region sync είναι συχνά πολύ αργό, οπότε πολλοί τρέχουν async και αποδέχονται ένα μικρό RPO.

## Failover, RPO & RTO

- **RPO (Recovery Point Objective):** πόσα δεδομένα μπορείτε να χάσετε — ορίζεται από sync vs async.
- **RTO (Recovery Time Objective):** πόσο μέχρι να επιστρέψετε — ορίζεται από το πόσο γρήγορα ανιχνεύετε την αποτυχία και προάγετε.
- Failover = ανίχνευση (health checks) → προαγωγή standby → repoint traffic (DNS/global LB). Αυτοματοποιήστε το, αλλά προφυλαχτείτε από **split-brain** (και οι δύο περιοχές νομίζουν ότι είναι primary) με ένα quorum/fencing token.

## Οπτική συνέντευξης

Η διερεύνηση: καταλαβαίνετε ότι το HA/DR είναι ένα **trade μεταξύ consistency, latency, και απώλειας δεδομένων** — όχι "απλά πρόσθεσε ένα replica". Καλό: active-passive με ένα standby. Εξαιρετικό: δηλώνετε RPO/RTO, sync-vs-async επιπτώσεις, και το ρίσκο split-brain. Παγίδα: να ισχυρίζεστε ότι το async δίνει μηδενική απώλεια δεδομένων, ή να θεωρείτε ότι το failover είναι ακαριαίο και lossless.

## Trade-offs & τρόποι αποτυχίας

- **Split-brain:** ένα network partition προάγει δύο primaries → αποκλίνοντα δεδομένα. Χρησιμοποιήστε quorum, fencing, ή μια witness region.
- **Το failback είναι δύσκολο:** αφού επιστρέψει το παλιό primary, το reconcile των αποκλινόντων writes είναι manual και επιρρεπές σε λάθη.
- **Κόστος:** το αληθινό multi-region περίπου διπλασιάζει το infra και προσθέτει cross-region egress bandwidth λογαριασμούς.
- **Το μη-δοκιμασμένο failover αποτυγχάνει:** DR που δεν έχει ποτέ δοκιμαστεί δεν θα δουλέψει στην πραγματική διακοπή — τρέξτε game-days.

Active-passive vs active-active

Sync vs async replication

Failover, RPO & RTO

Οπτική συνέντευξης

Trade-offs & τρόποι αποτυχίας

Σχετικές ερωτήσεις