What is geo-sharding and how do you handle data locality requirements?

Geo-sharding partitions data by geographic region, ensuring data for users/entities in a specific region stays in that region's data center. Critical for: data residency compliance (GDPR requires EU user data in EU), latency optimization (users read/write local data), disaster isolation. Implementation: (1) Region routing: DNS-based GeoDNS routes users to nearest regional cluster; API gateway in each region routes to regional database; (2) Data model: include region identifier in partition key: user_id = "EU_123456" or shard_key = (region, user_id). All data for a user stays in their region's shard; (3) Cross-region queries: avoided by design — each region is self-contained. If truly needed (global analytics), use async data export to central data warehouse; (4) User migration: when a user moves regions, migrate their data asynchronously while both regions serve the user temporarily. GDPR compliance considerations: right to erasure (delete all EU user data from all systems within 30 days), right to portability (export), data minimization (don't store EU data outside EU). Ensure backups, analytics pipelines, logs also respect geo-boundaries. Global entities: some data is inherently global (product catalog, shared configs). Options: replicate globally (eventual consistency), or designate a home region and cache elsewhere with TTL. Challenges: users traveling between regions, multi-region transactions (user in EU interacting with user in US), global uniqueness of IDs (use global UUID generation service, not auto-increment per region). Tools: Vitess (MySQL) with geo-partitioning, CockroachDB (built-in multi-region support), AWS Aurora Global Database.