Privacy as a Legal Right, Not a Feature
The General Data Protection Regulation (GDPR) is EU legislation that came into force in May 2018. It treats personal data privacy as a fundamental right of EU citizens and residents, not a product feature that companies can opt into or out of. It applies to any organization that processes personal data of people in the EU — regardless of where the organization itself is located. A US company with EU customers must comply.
GDPR grants individuals specific rights over their data:
- Right of Access: Users can request a copy of all data you hold about them.
- Right to Rectification: Users can demand corrections to inaccurate data.
- Right to Erasure ("Right to be Forgotten"): Users can demand deletion of their data, subject to certain exceptions.
- Right to Data Portability: Users can request their data in a machine-readable format.
- Right to Object: Users can object to certain types of processing, including direct marketing.
Each of these rights has engineering implications. "Right to be Forgotten" requires that you can find and delete a user's data across all systems — including backups, analytics pipelines, data warehouses, and third-party integrations. This is significantly harder than it sounds.
Data Residency: Where Data Lives Matters
GDPR restricts transferring personal data of EU residents to countries outside the EU/EEA unless those countries provide "adequate" data protection. The US was not considered adequate after the Schrems II ruling in 2020 invalidated the Privacy Shield framework. This created a legal requirement for many organizations to keep EU citizen data physically within the EU.
Beyond GDPR, many countries have enacted their own data residency laws: Russia requires Russian citizen data to be stored on Russian servers, China has strict data localization requirements under PIPL, and Brazil's LGPD has similar cross-border transfer restrictions.
The engineering consequence: You can no longer treat your database as a single global store. A single PostgreSQL cluster in us-east-1 that holds all global user data violates data residency requirements for multiple jurisdictions.
Geo-Sharding: The Architectural Response
The primary architectural pattern for data residency compliance is geo-sharding — partitioning your database by the geographic origin of the data subject, and routing each shard to infrastructure physically located in the appropriate jurisdiction.
Geo-sharding introduces significant operational complexity:
- Cross-shard queries are hard: Analytics that span all users now require federated queries across multiple regional databases.
- Deletion requests must propagate everywhere: When a user invokes their right to erasure, you must delete from the primary shard, all replicas, all backups, and all downstream systems that received that data.
- Legal Holds conflict with deletion: If a user is subject to a legal hold (e.g., their data is evidence in litigation), you may be legally required to preserve data that GDPR requires you to delete. Resolving this conflict requires legal counsel and technical mechanisms to flag records under hold.
Interviewers at companies with global user bases frequently ask: "How would you implement the right to be forgotten?" A weak answer says "just delete the row." A strong answer addresses: (1) finding all copies — primary DB, read replicas, backups, data warehouse, event streams, third-party integrations; (2) the backup problem — you cannot easily delete from a backup without restoring and re-dumping it, so some teams use encryption-based erasure (delete the encryption key, making the data unreadable); (3) the legal hold conflict; and (4) audit logging to prove deletion occurred.