Regional Isolation

The Independence Test

 question that exposes hidden coupling:

 "if every OTHER region vanished right now,
  could this region serve its users indefinitely?"

 honest answers usually reveal:

 ✗ global single-writer services (auth! feature flags!)
 ✗ shared databases masquerading as regional
 ✗ control planes living in ONE region
 ✗ third-party integrations pinned elsewhere
 ✗ deployment pipelines flowing through one region

 each shared dependency = a thread connecting all regions
 to one fate. regional isolation is the HUNT for those
 threads and the discipline of cutting them.

The Isolation Checklist Per Region

 full-stack independence requires:

 □ COMPUTE: app instances, autoscaling local
 □ DATA: regional primaries + replicas of others' data
 □ IDENTITY/AUTH: locally serving (replicated tokens/dirs)
 □ CONFIG/FLAGS: replicated store with local read path
 □ SECRETS: present + rotatable per-region
 □ QUEUES/EVENTS: regional brokers, cross-region bridges
 □ DEPLOYMENT: pipeline can target region independently —
   even if the PIPELINE control plane lives elsewhere,
   the region must not NEED it alive to RUN
 □ OBSERVABILITY: telemetry exported OUT (region down =
   still visible from survivors)
 □ DNS/TLS: certificates valid globally; routing independent

Shared Services: The Deliberate Exceptions

 some things resist full isolation — handle consciously:

 GLOBAL-BY-NEED (harden instead of replicate):
 - billing ledger? maybe genuinely centralized.
   → multi-AZ within home region + DR story explicit
 - ML model registry → replicate ARTIFACTS out; control
   plane can be central with cached fallbacks

 PATTERN: centralize the CONTROL PLANE,
 distribute the DATA PLANE.
 regions run autonomously on replicated state;
 coordination flows tolerate control-plane absence
 (last-known-good config caching!).

 document EVERY exception in the isolation matrix:
 service | mode | failure behavior when central dies

Testing Isolation Honestly

 claims require experiments:

 □ REGION-SEVERANCE drill: block cross-region links;
   measure what keeps working per region (expect surprises:
   flag-fetch loops stalling request paths, etc.)
 □ CONTROL-PLANE-LOSS test: kill central services;
   verify regions run on cached state for hours
 □ DEPLOY-DURING-PARTITION: pipeline resilience check
 □ THIRD-PARTY failover paths actually configured?

 findings become the isolation backlog. maturity is
 measured by how boring severance drills get.

Interview Framing

“Prove your regions are truly independent” scored shape: independence checklist applied to the design, shared-dependency hunt demonstrated (auth/config/deploy pipelines as usual suspects), control-plane/data-plane split pattern stated, severance-drill verification plan, isolation matrix artifact mentioned. Regional isolation questions are really asking whether you design for partial failure — the drill-based answer shows you expect to be wrong sometimes and verify anyway.