Menu

Earn Premium with Referrals

Invite your friends and earn Premium rewards through our referral program.

See how it works and start inviting friends.

Active-Passive
HLD

Active-Passive

The standby pattern — one region serves, another waits, and the promotion dance between them.

The Topology

 [region-A: ACTIVE]              [region-B: PASSIVE]
 serves 100% traffic             standby, replicating
     │                                ▲
     └──── async replication ─────────┘
          (data flows one way)

 passive variants by warmth:
   COLD:  infra defined (IaC), not running; restore on disaster
   WARM:  scaled-down stack live, replicas current;
          scale-out + promote when needed  
   HOT:   full-capacity idle fleet mirroring production

 traffic: DNS/global-LB points at A. B gets zero user load.

The Failover Sequence

 1. DETECT:    health checks fail / human declares disaster
 2. VERIFY data state: replication lag? last-synced position?
               (RPO math happens HERE — know the gap)
 3. PROMOTE B: replicas → primary; queues activate;
               caches cold-start (stampede watch!)
 4. REDIRECT:  DNS/LB switch to B (TTLs matter — low TTLs
               on failover-able records, pre-configured)
 5. VERIFY:    business-flow smoke tests before full traffic
 6. RUN degraded-awareness: capacity may differ from A's
 7. FALLBACK PLAN for later: returning to A needs
               reverse-replication strategy — plan it NOW,
               not after B runs alone for a week.

 typical warm-standby timeline: minutes if drilled,
 hours if improvised.

Design Decisions

DecisionOptionsGuidance
Replication modesync vs asyncsync couples latency+availability across regions — usually async with RPO accounting
Standby warmthcold/warm/hotRTO budget decides
Data promotedDB, queues, cachescaches rebuild; don’t replicate them
Split-brain guardfencing/consensusA must be PROVEN dead before B writes
 SPLIT-BRAIN is the classic killer:
 network partition (not death) → both regions think they're
 primary → divergent writes → reconciliation hell.
 prevention: quorum/fencing — writes require proof of
 exclusivity (lease tokens, witness nodes, consensus).

Active-Passive vs Active-Active

 AP strengths:
 + simple mental model (ONE writer, always)
 + no conflict resolution needed (single-region consistency)
 + cheaper than full AA (standby can be smaller)
 
 AP costs:
 − wasted idle capacity (or risky scaled-down standby)
 − RTO includes promotion+cutover time
 − region A's users eat the whole outage until failover

 choose AP when: strong single-region consistency suffices,
 DR budget moderate, write-conflicts would be nightmare material.
 upgrade to AA when: RTO seconds demanded or both regions
 should earn their keep serving traffic (multi-region lesson).

Interview Framing

“Design DR for an order system: minutes-class RTO, seconds-class RPO” scored shape: warm/hot active-passive diagram, async replication matching the RPO, promotion sequence WITH split-brain fencing called out, DNS-TTL detail, fallback-to-A planning mentioned, honest tradeoff vs active-active stated. The fencing mention separates people who’ve thought about partitions from people who’ve only read about failovers.

My Private Notes

Notes are auto-saved locally to this device.