How do you fulfill a GDPR erasure request across microservices?

WHAT THIS TESTS: This question probes whether you understand data ownership in distributed systems and the operational reality of GDPR Article 17. Interviewers want to see that you respect bounded contexts, know that deletion is an asynchronous and imperfect process, and can distinguish between hard deletion, anonymization, and crypto-shredding. They also care if you think about evidence and auditability rather than just flipping a deleted bit.

A GOOD ANSWER COVERS: A strong response walks through five phases in order. First, intake and validation, where the request is authenticated, scoped to jurisdictions and legal holds, and written to an append-only audit log. Second, event emission, where a durable right-to-erasure domain event is published to a message bus like Kafka or a pub-sub system with at-least-once delivery and idempotent consumers. Third, local execution, where each microservice independently handles the event within its own data store because no service should reach into another's database. The user service might purge PII, the order service might anonymize records into an aggregate shape that retains financial history, and the analytics service might delete or tokenize rows. Fourth, infrastructure hygiene, where you address backups with automated rehydration and re-deletion pipelines, cache eviction, search index removal, and log redaction. Fifth, verification, where a scheduled reconciliation job scans for residual identifiers and produces a completion certificate for the regulatory team.

COMMON WRONG ANSWERS: Red flags include proposing a single distributed transaction or saga that forces every service to delete data in lockstep, which creates tight coupling and fragility. Another mistake is assuming that soft deletes or a boolean isDeleted flag satisfy GDPR. Some candidates forget about cold storage backups, CDN edge caches, or read replicas, meaning the data is still restorable. Claiming that Kafka log compaction or immutable event stores automatically erase data is also a serious error because immutability and erasure are fundamentally at odds.

LIKELY FOLLOW-UPS: The interviewer might ask how you handle referential integrity when foreign keys span services, which you solve by replacing PII with opaque tokens or aggregate placeholders. They might ask about legal retention periods for orders or taxes, which means some data must be anonymized rather than deleted. They could also ask how you prove compliance to auditors, which points to your immutable request log and reconciliation reports.

ONE CONCRETE EXAMPLE: Imagine a user with an account in the user service, five orders in the order service, and clickstream events in the analytics service. Upon receiving a valid erasure request, you write the request to a compliance log and emit a UserErasureRequested event containing a correlation ID. The user service hard deletes the profile and overwrites the email hash. The order service replaces the user ID with a non-reversible token and retains order totals for seven years per tax law. The analytics service deletes all rows matching that user ID. A nightly reconciliation job queries a metastore for any remaining appearances in Elasticsearch or S3 backups and opens tickets for manual review if found.