GDPR Service System Design

The interviewer's prompt sounds like a compliance ticket: "We're a company with about 4,000 internal services and two billion user accounts. Under GDPR, a user can ask us to delete everything we hold about them, or to give them a copy of it. Design the central service that takes that request and makes sure every one of those services actually does it, on time, and that we can prove it afterwards."

The first version writes itself: a DELETE FROM users WHERE id = ? and a user.deleted event for anyone who cares to listen. It runs, it returns 200, and it is wrong. Lena, a user in Berlin with a nine-year-old account, clicks "Delete my account". Her profile row disappears. Her photos are still in the media store, her search history is still in a data lake partitioned by day, her old messages are in last week's database backup, her advertising ID is in a recommendations service nobody has touched since a reorganization, and her email address is sitting in three different log pipelines. Nobody can say which services held her data, so nobody can say whether they all deleted it. The law gives you one month.

The Trap Built Into "Delete My Data"

Two failures come up again and again:

• The DELETE Statement: treats erasure as a database operation, deletes the account row, publishes an event and calls it done. Signal: never asked where the data actually lives, or how anyone would know that every copy is gone.
• The Compliance Checklist: recites GDPR articles fluently (Article 17, Article 15, the one-month clock) and never designs the machine that makes 1,200 independently owned services act on them. Signal: knows the law, can't build the system the law demands.

The passing answer treats the problem as what it is: distributed coordination with a legal deadline and a burden of proof. A central orchestrator never touches a service's database. It takes the request, verifies who is asking, holds a 14-day grace period, then broadcasts a task to every registered data holder and tracks 1,200 acknowledgements against a deadline it computed the moment the request arrived. Each service deletes its own data through a shared SDK. Storage that has no DELETE (data lakes, event logs, backups) gets batched row-level deletes, retention limits and per-user keys that can be shredded. And a tombstone list stops deleted data from coming back through a restore or a replay.