Implement a GDPR Art. 17 right-to-erasure cascade across microservices using an event-driven fan-out pattern

Verified steps

1. On receipt of a verified erasure request, publish a user.erasure.requested event to a central message broker (e.g., Kafka topic or SQS queue) with a payload of {requestId, subjectId, requestedAt, legalBasis: 'Art17'} — do not include full PII in the event payload.
2. Each microservice subscribes to the erasure event topic; upon receipt, the service looks up all records referencing subjectId, deletes or anonymizes them according to its own data retention obligations, and publishes a user.erasure.completed.{serviceName} event with {requestId, status, recordsAffected, completedAt}.
3. A central DSAR orchestrator subscribes to all completion events and maintains a per-requestId completion matrix; once all registered services have reported completion or SKIPPED, the orchestrator marks the overall erasure COMPLETE and notifies the data subject.
4. Handle the Art. 17(3) exceptions in each service: if data must be retained for legal obligation, freedom of expression, or public-interest reasons, the service should report SKIPPED with a documented exception reason rather than DELETED.
5. Set a maximum completion SLA (e.g., 30 days) for each service; the orchestrator flags overdue services and escalates to your privacy team for manual intervention.
6. Store the completion matrix and all service-level responses in an immutable audit log for GDPR accountability; this log constitutes evidence of compliance with Art. 17 in the event of a supervisory authority inquiry.