Section 7: Nine Identifiers, Twelve Hundred Acks, One Clock - Deep Dive (Candidate-Driven)

Executive Summary: The interviewer hands you the wheel, and you pick the three places where the Privacy Request Orchestrator would actually fail. Identity resolution decides which data counts as Lena's. The fan-out protocol gets 1,200 services to act exactly once in effect, over a pipe that delivers at least once. The request state machine carries her request from RECEIVED to COMPLETED against a 30-day clock, with a 14-day grace period at the front. Each dive goes mechanism, then number, then trade-off, and each ends with the pushback it attracts.

The architecture from Section 6 is on the board, and the interviewer leans back: "You've got twenty minutes. Where do you want to go deeper?"

A weak answer goes to the export archive format or the dashboard. You go to the walls that hold the building up: "Three things. If identity resolution is wrong, we delete the wrong data or miss the right data, and the ack count still looks perfect. If the fan-out protocol is wrong, retries cause damage or acks lie. And if the state machine is wrong, we miss a legal deadline without anyone noticing. Let me take them in that order."

Deep Dive One: Identity Resolution, or Who Is Lena?

Lena isn't one key. She's nine: account ID u_7f3a9c, two email addresses, a phone number, three device IDs, an advertising ID, and a legacy ID from the fitness app the company acquired. The ad-serving service only knows her advertising ID. The fitness backend only knows the legacy ID. If the event said "delete u_7f3a9c", both services would answer NO_DATA, honestly and wrongly.

Mechanism. The identity team owns the graph. The orchestrator never copies it. Identity Resolution resolves the full set at fan-out time and freezes it into a snapshot keyed by request_id. Services call GET /v1/subjects/{subject_ref}/identifiers and get back only the identifier types they declared in privacy.yaml. The ads service sees one advertising ID. It never sees her phone number.

Why freeze it? Because the identity service is one of the 1,200 holders. Its own task finishes within the first hour of fan-out and deletes the links. Without the snapshot, reco-legacy (the straggler that finishes on day 23) would ask for Lena's identifiers and get back an empty set. The snapshot is encrypted and is destroyed when the request reaches COMPLETED.

Number. At most 1,200 identifier lookups per request, about 380 per second on average across all erasures (the same rate as erasure tasks). That's a cached point read, not a graph traversal.

Trade-off. Some data can never be attributed. A cookie that browsed the news app but was never tied to a sign-in has no edge to Lena in the graph. Be careful how you say this in the room. GDPR Art. 11 says that if a controller's purposes don't require identifying the person, it isn't obliged to acquire extra information solely to comply. So we don't build fingerprinting to find more of Lena. If she supplies something that links the cookie to her, it comes into scope.

The Pushback: "Why not let each service resolve its own identifiers?"
Because then you'd have 1,200 partial copies of the identity graph, each stale in its own way, and none of them able to show what was in scope. A regulator asks "which identifiers did you erase against?" and the honest answer is a single snapshot, not 1,200 guesses.

Quick check before moving on: