Topic 14.7
Data Privacy
In one line
GDPR-grade concerns in designs: retention, deletion, PII classification, consent, and the 'right to be forgotten'.
Think of it like this
A doctor's confidentiality: they can look at your medical records because they need to for treatment, but they can't gossip about them to unrelated people, and old records that are no longer needed eventually get shredded.
Key ideas
- 01
PII is data you must protect + delete on request — classification up front decides everything else.
- 02
Retention policies: data you don't keep can't leak — define and enforce tiers (30d logs, 7y financials).
- 03
Deletion: hard vs soft delete; event-sourcing systems need tombstones; backups carry PII — purge procedures must cover backups too.
- 04
Encryption at rest + access least-privilege + audit: the three mechanical walls for PII.
- 05
Consent & purpose-limitation: what you collect must serve the stated purpose — design the fields, not just the API.
- 06
Interview: 'logs are sampled and PII-stripped; PII lives in one encrypted store with strict access, and deletion flows cover backups'.
Explain without notes
GDPR 'right to erasure' and your event-sourced system — where does the difficulty actually sit?
Practice
Design the data-classification table + retention schedule + the erasure pipeline.
Trade-offs
- ↔
Privacy protections cost engineering + data usefulness (ML!) — the honest tension is regulated, not optional.
Run it in production
You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:
Completion checklist
I design with retention + erasure + PII-scoping as first-class, not retrofits.