Section 3: One Request a Second, Twelve Hundred Echoes - Scale Estimation & Workload Analysis

Executive Summary: This section derives the orchestrator's scale from the population the interviewer gave us. Intake turns out to be the smallest number in the design, at about one request per second. The real load comes from what each request turns into: a 1,200x fan-out of tasks and ledger writes, a 5 Gbps export stream with 385 TB of staging, and a tombstone filter small enough to ship to every ingestion path. Each number then gets to decide something, and each decision names the threshold at which it would flip.

The interviewer taps the first number on the board. "Two billion accounts. That sounds big. How big is this system, really?"

The candidate restates the inputs before multiplying anything: 2 billion accounts, about 4,000 services, of which 1,200 are registered as holding personal data. 400 of those are source-of-truth holders, including inferred profiles such as ad interests and recommendation features; the other 800 hold derived copies (caches, search indexes, replicas, feature-store copies) of data one of the 400 already owns. A long-tenure user like Lena has data in about 200 of the 1,200 holders (197 in her case). "The scale here doesn't live where you'd expect. Let me show you where it does live."

Step 1: Requests Are Tiny

Erasure:  2,000,000,000 accounts x 0.5%/year  = 10,000,000 / year
          10,000,000 / 365                     ≈ 27,400 / day
          27,400 / 86,400 s                    ≈ 0.32 / s

Access:   2x erasure                           = 20,000,000 / year
                                               ≈ 54,800 / day ≈ 0.63 / s

All DSRs: 30,000,000 / year                    ≈ 82,000 / day ≈ 0.95 / s

That comes to about one request per second for a company with two billion users. The interviewer pushes on the average: "Deletions aren't smooth. What happens after a privacy scandal?"

"Then a viral 'delete your account' campaign gives us a 10x day: about 274,000 erasures, or 3.2 per second. I'll size intake for a 30 per second burst, roughly 100x the average, because intake is the one place where turning a user away is visible. Everything behind intake gets smoothed. Nobody's deletion has to start within the same second it was requested; the 14-day grace period from Section 2 means it can't."