Your data is pinned per region, but login must be globally unique and admins want one global search. How do you build that?

Three things are being conflated

"Data must stay in the region" almost never means every byte associated with a person. It usually decomposes into a storage constraint on the regulated content, a processing constraint on where computation over that content happens, and an access constraint on who can reach it from where. A globally unique login and a global admin search collide with different parts of that, and treating them as one problem produces either a design that replicates everything or a design that cannot log anyone in.

The useful reframing is that residency applies to the payload, and both features need only keys. A uniqueness check needs to know that some identifier is taken and where its owner lives. An admin search needs to know which records exist and in which region, so it can ask that region for the detail. Neither needs the record itself to leave.

The global tier holds keys, not content

Run one small global directory whose schema you can print on a page. For each principal it holds a stable internal identifier, a token derived from the login identifier, and the home region. Nothing else earns a place there, and every proposal to add a field is a decision about whether that field may cross a border.

Uniqueness then becomes a claim on the token rather than a query over user tables. Signup asks the global directory to insert the token; a unique constraint there does the work, and the row records the region that will own the account. Login sends the same derivation, gets back a region, and redirects or proxies the authentication to that region, where the credential material and everything else lives. The credential itself never appears in the global tier, so a compromise of the directory yields a set of tokens and a residency map rather than an account database.

The honest part of this design is that the token is not anonymous. Which sort of hash you chose decides who can undo it, and the distinction is worth stating precisely. An unkeyed hash of an email address, or one under a salt shared across records, identifies a person to anybody who holds the address, because they simply recompute it and compare. A keyed hash — an HMAC under a secret held apart from the directory — cannot be recomputed that way, so the same guess-and-compare attack needs the key as well as the address. Neither is anonymisation: you hold the key, and you can always reverse the mapping through your own directory, which is what makes the token pseudonymous rather than anonymous. Key custody changes who is able to re-identify, not whether re-identification is possible. So the global directory is a store of personal data in a form that some regulators will accept as low-risk and others will treat as a transfer requiring a mechanism. That determination is not yours: you describe what the token is, what it is derived from, whether the key is held separately, and what an attacker who holds it can learn, and your privacy or legal function decides whether that placement is permitted. Designing as if the hash makes the problem disappear is the single most common error here, and an interviewer who has done residency work will be listening for it.

Search as fan-out, not as a central index

The tempting shortcut is a central search cluster that everything replicates into, because it is the only shape that makes ranking easy. It is also the shape that copies the regulated payload into one place, which is exactly what you were told not to do. Sanitising the documents down to non-regulated fields sounds like a fix until you notice that the fields an admin searches on — name, email, company, address — are the regulated ones.

Fan-out inverts it. The query goes to every region the caller is entitled to query, each region searches its own index over its own data, and each returns matches. What comes back is where the decision lies: returning full records recreates the copy you avoided, so return the minimum needed to render a result list and accept that the aggregation layer holds those fields transiently in memory to merge and sort them. Whether that transient handling counts as a transfer depends on the regime and the aggregator's location, which is again a question you frame rather than answer.

Concern	Central index	Regional fan-out
Where the payload rests	One cross-border copy	Only in the owning region
Ranking across regions	Straightforward	Approximate, merged at the edge
Latency	Single hop	Bounded by the slowest region
A region is unavailable	Results still returned, silently stale	Partial results, and you must say so
New region onboarding	Replication and reindex	Add an endpoint to the fan-out

The row worth arguing about is the fourth. A central index degrades invisibly; fan-out degrades visibly, and a partial result set that is not labelled as partial is a correctness bug that will eventually be an incident, because someone will conclude a customer does not exist.

The paths that leak without a design decision

Residency reviews pass and residency still breaks, because the leaks are in the plumbing rather than the data model. A single global identity provider that caches user attributes. Error tracking that ships a stack frame containing a serialised customer object to a vendor in another region. Metrics labelled with an email address. A CDN that terminates in the nearest edge and logs the path, which contains an account reference. A search autocomplete service that learns from queries. Nightly exports into a warehouse that was built before the requirement existed. Support tooling and screen-sharing sessions, where a person in the wrong country reads the data even though the bytes never moved.

The global tier makes these easier to police for one specific reason: it gives you a short, explicit list of what is allowed to be global, so anything else appearing outside its region is by definition a defect rather than a debate. That inversion — deny by default, with a named exception list — is the part of the answer that shows you have operated one of these systems rather than drawn one.

Migration is the case nobody plans for

Users move countries, companies restructure, and regulators change the rules about a jurisdiction you already store data in. So the home region has to be mutable, and moving it is a data migration with a period during which records exist in both places. Decide up front whether the old region's copy is deleted or retained under some other obligation, whether identifiers are stable across the move, and what happens to the audit trail — which usually must stay where the actions happened, meaning a migrated user's history is legitimately split across two regions and any tool that reads it needs to handle that.

Residency designs survive on the discipline of the global tier. Write down the handful of fields allowed to be global, make everything else deny-by-default in its region, and describe the pseudonymous token honestly rather than treating a hash as a licence to replicate.