I have watched teams read a regulation like this, all one sentence of it, nod, and file it under compliance, as if it were a form to sign before launch. Personal data and transaction records of in-country users must be stored and processed within the country, and the keys that protect them must be held under domestic control. Filing a rule like that under compliance is the mistake. It reaches into your topology, your key management, your analytics, and your on-call rotation, and treating it as a checkbox is how you find out the expensive way.
I led the platform for a payments business that moved billions in volume across a region where one large market had exactly this rule. We already ran a clean, centralized stack: one set of regions, one data lake, one analytics warehouse, one place where the data scientists worked. That centralization was most of why the thing was cheap and fast. The residency rule asked us to take a knife to it.
What the rule actually says, translated to architecture
A residency requirement is three claims wearing one coat. First, the data at rest lives inside the border. Second, the processing that touches raw records also happens inside the border, not just the storage. Third, the cryptographic keys are held domestically, which means your central security team no longer gets to be the sole root of trust. People hear the first claim and miss the other two. The third breaks naive designs, because it severs the assumption that there is one global place where everything can be decrypted and joined.
The question stops being “where do we put the database.” It becomes “what is the smallest set of things that must stay inside the border, and what is the largest set of things we can still run centrally without violating the rule.” Get that line wrong in either direction and you pay. Draw it too tight and you have rebuilt your entire platform once per country, a cost that compounds for the life of the business. Draw it too loose and you have a finding in an audit, a regulator conversation you do not want, and possibly a market you can no longer operate in.
The topology it forced
We landed on a hybrid that I would draw the same way today.
The boundary is the architecture. Raw records and keys never cross it. Only de-identified aggregates do.
Inside the border we ran a full in-country data plane: the transactional databases, the raw event store, the processing that operated on identifiable records, and a domestic key management service that the in-country deployment held. Authorization, settlement, anything that had to read a real card token or a real customer record, ran there and only there. That cluster was, for legal purposes, a small self-contained version of the whole company.
Outside the border, in our central region, ran everything that did not need to see a raw in-country record to do its job: global routing config, the merchant catalog, the fraud model training that worked on features rather than raw PII, the company-wide dashboards. The connective tissue between the two took the real design work. The rule was narrower than “never share anything.” Raw identifiable records could not cross the boundary, while aggregates and de-identified derivatives could.
The keys are the hard boundary, more than the storage ever was. Residency makes key management a topology decision instead of a security checkbox. Once the in-country deployment holds its own keys, the central plane physically cannot decrypt those records even if it pulled the bytes. That is the property you actually want, because it makes a residency violation an active mistake rather than a default. What the central plane relies on is not a bucket policy but math, and the absence of a key.
Cross-border analytics on aggregates only
The business still wanted one view of the world. Country managers wanted to compare markets. The fraud team wanted patterns that only show up across borders. The board wanted a single number. None of that requires raw records to cross the line, and the moment you accept that, the design opens up.
We ran the heavy aggregation inside the border, on the raw data, and let only the output leave. Country-level rollups. Cohort counts above a minimum group size so a row could never be traced back to a person. Model features that had already been stripped of the identifiers. The central warehouse stitched these together into the global picture and never once held an in-country customer record. The rule we enforced was blunt, and I would keep it blunt: nothing crosses the boundary unless it has been aggregated or de-identified inside the boundary first. No exceptions for “just this one debug pull,” because every exception is the one the auditor finds.
The cost of this is real and worth saying out loud before you start. You give up ad-hoc joins across all your raw data in one place. A data scientist who wants to correlate a raw behavior in one market with a raw behavior in another cannot, and that limit is the constraint doing exactly what it is meant to, not a bug to be fixed later. You move the analysis to where the data lives instead of moving the data to where the analyst sits, which feels backwards if you grew up on a central lake, and is correct.
The engineering cost of getting it wrong
I have cleaned this failure mode up before. A team treats residency as a deployment detail, ships the global architecture, and bolts a regional database on at the end with a replication job feeding the central lake “for analytics.” It works in the demo and passes the first internal review, because the diagram has a box labeled in-country. Someone eventually looks at what the replication job is actually copying: raw records, leaving the border, into a lake the central team can read with central keys. At that point you are not fixing a config, you are re-architecting a live payments system under a regulator’s deadline, which is the worst possible time to discover that decryption was centralized.
The other expensive mistake is the opposite one: panicking and rebuilding the entire platform per country because someone decided the safest reading is to keep everything in. That is how you end up operating five copies of your company, each drifting from the others, each with its own on-call, each a place a bug can hide. The real skill is restraint: finding the true minimum that must stay inside and letting everything else leave as disciplined aggregates, rather than hoarding data behind the border because hoarding feels safer.
Two things made the hybrid survivable, and both are unglamorous. The boundary had to live in code, not in a slide. We made the central pipelines structurally unable to request raw in-country fields, so a residency violation would fail at build time rather than surface in an audit a year later. The in-country deployment also had to be a first-class part of the platform, deployed by the same automation as everything else, never a hand-managed pet the central team forgot how to operate. A residency island that only one person understands is its own kind of outage waiting to happen.
Residency reaches engineers as a legal problem, something compliance owns and hands over near the end, though the dependency runs the other way. The sentence is short, and the architecture it implies is the largest single force shaping where your data lives, what your keys can do, and which queries are even possible. So I decide the boundary first, deliberately, with the people who write the code in the room, because the alternative is having it decided later by an auditor, on a schedule I do not control.