Geo-Sharding & Data Residency
You'll learn to
- -Explain why regulations like GDPR affect data placement
Data Residency Requirements
GDPR in Europe and similar regulations elsewhere impose a constraint that has nothing to do with performance: certain user data must physically stay within specific geographic or legal boundaries, full stop. This turns "where does this data live" from a purely technical decision into a compliance requirement.
Geo-Sharding
Instead of (or in addition to) sharding by hash or key range, as the earlier Sharding chapter described, geo-sharding partitions data by the user's region. A European user's data lives on European infrastructure and simply never replicates outside it, satisfying the legal requirement, but at the cost of new edge cases: what happens when that user travels to another continent, or when an internal analytics query needs to aggregate a metric across every region at once?
A user's data is pinned to their home region's shard by law, not by load; it never replicates to another region's database at all.
These edge cases turn geo-sharding from a storage detail into an architectural one: it touches request routing, caching policy, and even how you design your APIs, not just where a database file happens to sit.
A European user on a business trip to New York opens your app. Their data is geo-sharded to EU-only infrastructure per GDPR. What happens to their experience?
"They'd just be routed to the EU region like normal, a bit slower."
"Exactly that trade-off has to be made explicit: their request now round-trips across the Atlantic on every action, since their data legally cannot live on or be cached from US infrastructure. Some systems accept that latency hit as the cost of compliance; others add a compute-only presence in the US region that talks back to EU storage for just that user's requests, cutting compute latency while never letting their actual data cross the boundary. Which one is right is a product decision as much as a technical one."