Si projektoni një DB multi-region për HA dhe DR?

Question

IT Interview Practice · Accepted Answer

Replikoni bazën nëpër rajone dhe zgjidhni topologjinë sipas nevojës: **active-passive** (një writer, një warm standby që merr përsipër në failover) për thjeshtësi dhe konsistencë të fortë, ose **active-active** (writers të shumtë) për write latency të ulët me koston e conflict resolution — pastaj zgjidhni **sync vs async replication** për të bërë kompromisin durability kundër latency, dhe përcaktoni objektiva eksplicitë **RPO/RTO** që nxisin 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** ka një primary që trajton shkrimet dhe standbys që vetëm lexojnë; në dështim ju **promovoni** një standby. Është i thjeshtë dhe shmang write conflicts, por kapaciteti passive rri idle dhe failover-i ka një hendek. **Active-active** lejon çdo rajon të pranojë shkrime për latency lokale dhe pa promovim failover — por dy rajone mund të editojnë të njëjtin row njëkohësisht, kështu që *duhet* të zgjidhni conflicts (last-write-wins, CRDTs, ose merge në nivel aplikacioni). Shumica e ekipeve fillojnë active-passive; active-active është për write latency global që vërtet nuk mund ta arrini ndryshe.

## Sync vs async replication

Ky është kompromisi thelbësor durability/latency. **Synchronous:** primary pret që replica remote të bëjë acknowledge para se të bëjë commit — **RPO = 0** (pa humbje të dhënash në failover) por çdo shkrim paguan cross-region round-trip latency (~dhjetëra ms), dhe nëse replica është e paarritshme, shkrimet ngecin. **Asynchronous:** primary bën commit lokalisht dhe dërgon ndryshimet pas — shkrime të shpejta, por një humbje rajoni mund të humbë sekondat e fundit (**RPO > 0**). Cross-region sync shpesh është shumë i ngadaltë, kështu që shumë ekzekutojnë async dhe pranojnë një RPO të vogël.

## Failover, RPO & RTO

- **RPO (Recovery Point Objective):** sa të dhëna mund të humbni — vendoset nga sync vs async.
- **RTO (Recovery Time Objective):** sa gjatë derisa të ktheheni — vendoset nga sa shpejt zbuloni dështimin dhe promovoni.
- Failover = zbulo (health checks) → promovo standby → ridrejto trafikun (DNS/global LB). Automatizojeni, por ruajuni nga **split-brain** (të dy rajonet mendojnë se janë primary) me një quorum/fencing token.

## Këndvështrimi i intervistës

Hetimi: a e kuptoni se HA/DR është një **kompromis mes konsistencës, latency, dhe humbjes së të dhënave** — jo "thjesht shto një replica". Mirë: active-passive me një standby. E shkëlqyer: deklaroni RPO/RTO, implikimet sync-vs-async, dhe rrezikun e split-brain. Kurthi: pretendimi se async jep zero humbje të dhënash, ose supozimi se failover-i është i menjëhershëm dhe pa humbje.

## Kompromiset & mënyrat e dështimit

- **Split-brain:** një partition rrjeti promovon dy primaries → të dhëna divergjente. Përdorni quorum, fencing, ose një witness region.
- **Failback është i vështirë:** pasi primary-i i vjetër kthehet, rakordimi i shkrimeve divergjente është manual dhe i prirur ndaj gabimeve.
- **Kosto:** multi-region i vërtetë përafërsisht dyfishon infrastrukturën dhe shton faturat e cross-region egress bandwidth.
- **Failover-i i patestuar dështon:** DR që nuk provohet kurrë nuk do të funksionojë në ndërprerjen reale — bëni game-days.

Active-passive vs active-active

Sync vs async replication

Failover, RPO & RTO

Këndvështrimi i intervistës

Kompromiset & mënyrat e dështimit

Pyetje të ngjashme