SYSTEM DESIGN #05 · INTERVIEW GUIDE
Privacy-Safe Measurement Framework
Privacy regulation isn’t a checkbox — it’s an architectural constraint that reshapes every data pipeline you build. GDPR, CCPA, and the death of third-party cookies have forced every ad-tech company to rethink measurement from the ground up. This system shows you how to collect meaningful marketing signals without collecting personal data: consent-gated event routing, HMAC-SHA256 hashing at the point of capture, k-anonymity thresholds (k≥100) that prevent individual re-identification, and Trusted Execution Environments for aggregation that even the operator cannot inspect. The result is a measurement framework that satisfies DPAs in 50 countries while still delivering the ROAS and conversion lift signals that marketing teams depend on. After this guide you will be able to design a privacy-safe data pipeline that legal, engineering, and marketing can all agree on.
GDPRk-AnonymityDifferential PrivacyNitro EnclaveHMAC-SHA256
💡
The Gist — What Problem Are We Solving?
Measuring ad performance without invading anyone’s privacy
Privacy laws and browser changes have broken traditional tracking. This system measures ad performance using only aggregated anonymised signals — checks consent first, routes through Privacy Sandbox APIs for unconsented users, suppresses results with fewer than 100 people, and adds mathematical noise to prevent reverse-engineering individuals.
💬Think of it as a privacy filter — you still get accurate campaign numbers, but individual people are mathematically invisible.
These are the capabilities the system must deliver — what users and operators can actually do with it.
✅
Consent Management
✅Parse IAB TCF 2.0; route by consent tier; record per-user consent state
🔐
Anonymisation
🔐HMAC-SHA256 hash all PII; k-anonymity suppression (k≥100); differential privacy ε=0.1
🌐
Privacy Sandbox
🌐Attribution Reporting API; Topics API; Aggregation Service integration
🖥️
Server-Side APIs
🖥️Meta CAPI; Google Enhanced Conversions; TikTok Events API fallback
🌍
Data Residency
🌍EU data processed and stored in EU only; APAC data in APAC region
⚡
Non-Functional Requirements
These define how well the system must perform — the quality attributes that separate a toy from a production system.
🔐 PII Storage
🔐Zero plain-text PII; HMAC-SHA256 with rotating secret
👥 k-Anonymity
👥Suppress any report bucket with <100 unique users
📐 Differential Privacy
📐Laplace noise with ε=0.1 added to aggregated counts
🌍 Data Residency
🌍Strict regional processing; cross-border transfer blocked
📅 Compliance
📅GDPR + CCPA + PDPA; audit log 7-year retention
📊
Key Metrics — The Numbers That Define This System
The headline numbers to know cold — and be ready to explain how each one is achieved.
k≥100
suppression threshold
🏗️
System Architecture Diagram
Full data flow from source to serving. Each layer scales independently.
Ingestion
→
→
[Consented] Standard Pipeline
hashed IDs) | [Unconsented] Privacy Sandbox APIs
→
Anonymisation Layer
hash + k-anon + DP noise + residency
↓
🗺️
End-to-End User Journey
Trace a single request end-to-end — the story interviewers want you to tell fluently.
1
User visits page
— CMP loads; user sees consent banner; choice recorded in Consent Store
2
Consented user
— Standard pipeline: event fires with HMAC-hashed user ID; server-side CAPI call made
3
Unconsented user
— Privacy Sandbox ARA: browser registers source event; no user ID sent to server
4
Aggregation
— Aggregation Service collects encrypted reports from browsers; decrypts in TEE
🔭
High-Level Design — Component Breakdown
Core components — each with a single, well-defined responsibility. The key architectural insight: each layer scales independently, and failure in one component is isolated from the rest.
1 — User Event
Handles responsibilities for the User Event layer. Designed for independent horizontal scaling — additional instances added without architectural changes. Communicates asynchronously with adjacent components to maximise throughput and fault isolation.
2 — CMP Gate
Handles responsibilities for the CMP Gate layer. Designed for independent horizontal scaling — additional instances added without architectural changes. Communicates asynchronously with adjacent components to maximise throughput and fault isolation.
3 — Router
Handles responsibilities for the Router layer. Designed for independent horizontal scaling — additional instances added without architectural changes. Communicates asynchronously with adjacent components to maximise throughput and fault isolation.
4 — Anonymiser
Handles responsibilities for the Anonymiser layer. Designed for independent horizontal scaling — additional instances added without architectural changes. Communicates asynchronously with adjacent components to maximise throughput and fault isolation.
5 — Privacy Sandbox
Handles responsibilities for the Privacy Sandbox layer. Designed for independent horizontal scaling — additional instances added without architectural changes. Communicates asynchronously with adjacent components to maximise throughput and fault isolation.
6 — Report Store
Handles responsibilities for the Report Store layer. Designed for independent horizontal scaling — additional instances added without architectural changes. Communicates asynchronously with adjacent components to maximise throughput and fault isolation.
🔬
Low-Level Design — Deep Dives
Deep dives worth explaining in detail in any senior engineering interview. For each: know the data structure, the algorithm, the why, and the trade-off you made.
1 — Consent Management Gateway
CMP · GDPR · CCPA
CMP integration layer intercepts all SDK event calls. Checks consent signal from browser’s localStorage (IAB TCF 2.2 consent string) or server-side consent flag. Routes consented events to standard pipeline. Routes non-consented events from EU users to privacy-safe aggregation pipeline. US non-opted-out users routed to standard pipeline under CCPA. Consent updates trigger retroactive pipeline re-routing for in-flight events.
def route_event(event, consent):
if consent.gdpr_applies and not consent.analytics_granted:
return privacy_pipeline.enqueue(event.anonymise())
return standard_pipeline.enqueue(event)
2 — HMAC Hasher
SHA-256 · PII Removal
PII fields (email, phone, first_name, last_name, address) are hashed at the point of SDK collection using HMAC-SHA256 with a rotating server-side secret. Raw PII never written to any storage system. Hash is deterministic — same email always produces the same hash for cross-device matching. Secret rotation happens every 90 days; old hashes re-computed during a grace period to maintain identity graph continuity.
import hmac, hashlib
def hash_pii(value, secret):
return hmac.new(
secret.encode(), value.lower().encode(),
hashlib.sha256
).hexdigest()
3 — k-Anonymity Aggregator
k≥100 · Query-time Check
Aggregation API enforces k-anonymity at query time: any cohort with fewer than 100 members returns a suppressed result rather than the actual count. Cohort definition is derived from the query dimensions (country, channel, campaign, device_type). The minimum granularity that passes k≥100 is determined by iteratively relaxing the cohort definition (e.g., drop device_type, then drop campaign) until the threshold is met. Response includes the achieved_k value so callers can understand the reporting granularity.
def aggregate(query, min_k=100):
result = db.aggregate(query)
if result.cohort_size < min_k:
return {'suppressed': True, 'reason': f'cohort<{min_k}'}
return result
4 — TEE Aggregation Service
Nitro Enclave · ε-DP
AWS Nitro Enclave runs the Differential Privacy aggregation for ML training pipelines. Input: hashed event stream. Output: aggregated counts + Laplace noise (ε=1.0). Enclave attestation document signed by AWS — verifiable by auditors. Noise calibration: Laplace(sensitivity/ε) where sensitivity = max contribution of one user = 1 event per window. At 1M events per cohort, noise of ±1/ε = ±1 is imperceptible (<0.0001% relative error).
# Inside Nitro Enclave
def dp_aggregate(events, epsilon=1.0):
true_count = len(events)
sensitivity = 1 # one user contributes at most 1 event
noise = np.random.laplace(0, sensitivity/epsilon)
return true_count + noise
⚖️
Trade-offs & Decision Log
Every senior interview comes down to these decisions. Know the exact trade-off, the reasoning, and the specific numbers that justify each choice.
⚖️ k-Anonymity vs Differential Privacy
✓
k-Anonymity (k≥100) ✅ Primary
- Deterministic — every aggregate is guaranteed non-re-identifiable
- Simple to audit and explain to regulators
- Can be computed without cryptographic overhead
- Vulnerable to homogeneity and background knowledge attacks
→
Differential Privacy (ε-DP)
- Mathematically provable privacy guarantee
- Adds calibrated Laplace/Gaussian noise
- Noise can make small cohort metrics unusable (high relative error)
- Harder to explain to non-technical stakeholders
💡Decision: k-anonymity for reporting APIs (regulator-friendly); DP with ε=1.0 for ML model training pipelines
⚖️ Consent Before Collection vs Consent Before Use
✓
Consent Before Collection ✅ Chosen
- Cleanest GDPR interpretation — no data collected without consent
- Simplest architecture — CMP gate at SDK level
- No risk of storing then needing to purge data
- May miss attribution for non-consenting users
→
Consent Before Use (collect all, gate on use)
- Higher event coverage — nothing missed at collection
- Requires storing non-consented data temporarily
- Purge-on-demand is complex and error-prone
- Regulatory grey area in Germany, France, Netherlands
💡Decision: Consent before collection for EU traffic; collect-then-filter acceptable for US traffic under CCPA opt-out model
🎯Interview Questions — Answered
The exact questions interviewers ask — with production-grade answers
Q1
How do you measure campaign performance when data is k-anonymised?
k-anonymity affects reporting granularity, not overall measurement accuracy. At k=100: country-level and channel-level metrics always have sufficient cohort size (millions of users). Campaign-level metrics are reportable for all campaigns with >100 conversions in the window. Creative-level breakdown is suppressed for creatives with <100 conversions and replaced with 'Other' to protect privacy. The system pre-aggregates at ingestion time — raw events are never stored post-hashing, so the k-anonymity check happens at query time against the aggregated table.
Q2
What is the architecture of the Trusted Execution Environment (TEE)?
The TEE is an AWS Nitro Enclave (or Azure Confidential Computing equivalent). The enclave runs the aggregation computation in an isolated memory region that even AWS cannot inspect. Inputs are: hashed event streams from consented users. Output: aggregated conversion counts, ROAS, and lift measurements. The enclave’s cryptographic attestation document proves to auditors that the computation ran on unmodified code without data exfiltration. This architecture is required by Google’s Privacy Sandbox APIs (Attribution Reporting API, FLEDGE) and enables measurement that satisfies the most stringent privacy requirements.
Q3
How do you handle consent withdrawal (right to be forgotten)?
Consent withdrawal triggers a four-step pipeline within 30 days (GDPR requirement): (1) Event ingestion blocked immediately — CMP gates all new events for user. (2) Identity graph nodes for canonical_id deleted from Union-Find and Neptune. (3) Raw event table: user_id_hash column NULLed in S3 Iceberg via partition rewrite (cannot delete individual rows from Iceberg efficiently). (4) Aggregated tables: checked for k-anonymity violation — if canonical_id deletion would expose a cohort below k=100, the entire cohort row is deleted. Process is fully automated and confirmed within 24 hours; 30-day deadline is an internal SLA, not the maximum.
System Design Series · Every Tuesday & Thursday
Level up your system design interviews
Each post covers Gist, Functional & Non-Functional Requirements, Key Metrics, System Diagram, User Journey, HLD, LLD, and Trade-offs & FAQs.
Subscribe to never miss a post →
Previous Articles
Categories: System Design
Tags: consent, differential privacy, gdpr, interview prep, k-anonymity, measurement, privacy, system design
Leave a Reply