Section 6: Track Everything, Delete Nothing - High-Level Architecture

Executive Summary: This section draws the Privacy Request Orchestrator as two halves. A small control plane accepts, schedules, dispatches, tracks and proves each request. A per-service side, built on a shared Privacy Agent SDK, does the actual deleting inside each of the 1,200 registered holders. Between them sit a transactional outbox, which keeps the ledger and the broadcast log from ever disagreeing, and an authenticated ack API, which turns "we deleted it" into a recorded fact. We walk Lena's erasure through every box and list what breaks when each component fails.

The interviewer slides the marker across: "Draw it." Before drawing anything, you say the sentence the whole diagram has to respect.

You: "The orchestrator never touches anyone's data. Each service deletes its own. The orchestrator decides who has to act, by when, and whether they did. Everything I draw falls on one side of that line or the other."

The Control Plane

• Intake API handles verification (re-authentication plus 2FA in session), the Idempotency-Key, and a burst buffer sized for 30 requests/s, about 100× the 0.32/s erasure average. It stamps legal_deadline at receipt (the earlier of receipt + 30 days and the same date next month) and returns 202.
• Request Ledger is the strongly consistent store from Section 5. It holds the request rows and the task rows, partitioned by request_id. At ≈1,900 writes/s (≈19,000/s peak), one cluster is enough; an ack that updates an indexed column spans splits, which is fine at that rate.
• Orchestrator is a stateless state machine. Its deadline scanner runs every minute, picks rows whose next_action_at has passed off the (scan_shard, state, next_action_at) index, and moves each one forward with a compare-and-set. The scan_shard = hash(request_id) mod 64 prefix stops rising timestamps from hotspotting one split; each scanner worker owns a shard range.
• Dispatch Log is the durable broadcast topic. Every holder reads it as its own consumer group, and topic retention is 14 days.
• Status/Ack API is the only way a task changes state. The caller's mTLS identity must equal the service_id in the path.
• Data Holder Registry, Identity Resolution, Audit Log and Notifier are the supporting cast. The registry says who must act. Identity Resolution says which identifiers they act on (the claim-check payload). The Audit Log records proof without names. The Notifier tells Lena what happened and tells owning teams what is late.

Interviewer: "Why not have the orchestrator run the deletes itself? One service, one place to get it right."

You: "Because it would need write credentials to 1,200 services' databases and would have to track 1,200 schemas that change weekly, quietly missing new columns while owners lose accountability. Fire-and-forget broadcast fails the other way: no acks, so there's nothing to prove completeness with. So: central orchestration, decentralized execution. The flip is shared platform storage, where the platform team owns the schema, so a central connector is the right owner there."

Quick check before moving on: