Section 5: Proving It Without Remembering Her - Data Modeling

Executive Summary: This section designs what the Section 4 calls actually write. Starting from access patterns, we derive six records: the privacy_request, the dsr_task ledger with its seven task states, the data_holder registry, the read-only identity_links, the tombstone, and the hash-chained audit_event. We choose a strongly consistent transactional store because "are all 1,200 tasks done?" has to be exact, not eventual. We size every table from the numbers ledger. And we face the minimization paradox head on: the orchestrator must prove it erased Lena while keeping as little about Lena as it can.

The interviewer points at the PUT /v1/requests/{request_id}/tasks/{service_id} line on the whiteboard: "Every one of those writes lands somewhere. What's the schema?"

You don't pick a database yet. You list the access patterns first, because in this system they decide almost everything:

1. Create one request with its legal deadline fixed at receipt (Section 2's rule: compute it once, store it, never recompute).
2. Create 1,200 task rows for that request in one go at fan-out.
3. Transition one task on each ack, with a compare-and-set so a stale retry can't overwrite a terminal state.
4. Answer "is this request done?" exactly, thousands of times a day.
5. Find overdue work: every minute, the deadline scanner asks for tasks whose next_action_at has passed.
6. Answer a regulator months later without exposing who the subject was.

Patterns 3 and 4 together are the heart of it: conditional single-row updates plus exact per-request accounting. Hold onto that pair. It will pick the store.

The Entity Map

Six core records plus a small hold table. Three change at request speed (privacy_request, dsr_task, audit_event). The registry changes when teams ship, and identity_links belongs to someone else entirely.