Data Residency

The Regulatory Map

 data-residency regimes shape architecture directly:

 GDPR (EU):        personal data of EU subjects; transfer
                   restrictions outside EU; erasure rights
 CCPA/CPRA (CA):   disclosure/deletion duties
 data-localization laws (CN, RU, IN-sectoral): storage
                   PROCESSING within borders mandated
 sector rules:     HIPAA (health), PCI (payments), finance
                   sovereignty requirements

 the design consequence: "just replicate globally" is often
 ILLEGAL for personal data. residency is an architectural
 input, not a policy afterthought.

Architectural Patterns for Residency

 REGIONAL PINNING:
   EU-users' personal data lives & processes in EU regions.
   homing model (data-locality lesson) becomes LEGAL model:

   [EU region: EU personal data — never leaves]
        │ non-personal/aggregated only crosses borders
   [US region: US data]...

 CLEAN-CROSSING patterns for global features:
 - PSEUDONYMIZATION before export: user-ids tokenized;
   analytics sees stable tokens, not identities
 - AGGREGATION at edge: only counts/trends leave region
 - SEPARATE KEY DOMAINS: encryption keys per region,
   held IN-region → cross-region copies unreadable ✓
   ("data can replicate; keys don't" pattern)

 ERASURE machinery (GDPR Article 17):
   delete-user must reach EVERY store including replicas,
   backups eventually, downstream consumers —
   event-driven deletion propagation + tombstones.

The Compliance-Architecture Interface

 engineers need fluency in both directions:

 FROM legal/compliance, extract precisely:
 □ which data CLASSES are restricted (fields, not vibes)
 □ which OPERATIONS are allowed cross-border (storage?
   processing? display? transient transit?)
 □ retention MINIMUMS (finance) vs MAXIMUMS (privacy)
   — they coexist! schema for both.

 TO legal, present honestly:
 □ data-flow diagrams per class (where it lands, replicates)
 □ subprocessor/cloud-region inventory
 □ deletion-propagation guarantees + timing reality
 □ breach-detection coverage per jurisdiction

 the artifact binding both: DATA CLASSIFICATION MATRIX
 driving storage/replication config automatically.

Design Consequences Checklist

 □ homing assignment captures residency zone at signup
 □ replication topologies respect zones (no naive global sync!)
 □ global features audited: does THIS path move personal data?
 □ support tooling: admins seeing EU data FROM US consoles
   = transfer question (break-glass with audit trails)
 □ backups: regional or encrypted-with-in-region-keys
 □ ML training pipelines: training-data residency!
 □ observability payloads: logs/traces leak PII across
   borders constantly — scrub/tokenize at source

Interview Framing

“Global product with EU users under GDPR — how does the architecture change?” scored answer: pinning-by-zone via homing model, clean-crossing techniques (pseudonymize/aggregate/key-separation), erasure propagation as designed feature, logs-and-backups leakage paths called out, classification-matrix as living artifact. Residency questions test whether you treat regulation as an engineering constraint to design around — because that’s exactly what it is.