Design Contact Tracing

Hard45 min
1 / 30
understanding8 min read

Problem statement: privacy-preserving exposure notification

How Problem statement: privacy-preserving exposure notification (understanding) informs Contact Tracing architecture and interviewer depth.

Problem statement: privacy-preserving exposure notification

National-scale BLE proximity logging without collecting identity or GPS.

Numbers to state early

  • Metric A: 180M installed apps
  • Metric B: 14-day TEK window
  • Metric C: 2m RSSI threshold

Mechanism

Frame the product as decentralized matching: phones hold encounter logs locally; the server only distributes diagnosis keys after voluntary positive report. Never promise real-time location tracking—that violates the Apple/Google privacy model interviewers expect.

Failure and edge cases

  • False positives when RSSI threshold is too loose in crowded transit
  • Clock skew breaking TEK day boundaries across time zones
  • Orphaned diagnosis keys if upload succeeds but CDN purge fails

When discussing Problem statement: privacy-preserving exposure notification, never place a central encounter warehouse—phones match TEKs locally. Cite 180M installed apps before drawing components. Flow emphasis: Citizen phone → BLE scanner → Exposure server.

Design pressure specific to exposure notification

Operators running BLE scanner under this section must honor opt-out wipes, 14-day TTL eviction, and signed bundle freshness. Battery caps on 2m RSSI threshold drive duty-cycle tuning.

Java

javaOne Dark Pro
1public final class RollingProximityId {
2 private final byte[] rpid;
3 private final Instant intervalStart;
4 private final int intervalNumber;
5
6 public boolean matchesInterval(Instant encounterAt, Duration tekPeriod) {
7 long day = encounterAt.getEpochSecond() / tekPeriod.getSeconds();
8 return day == intervalNumber;
9 }
10}

Python

pythonOne Dark Pro
1@dataclass(frozen=True)
2class RollingProximityId:
3 rpid: bytes
4 interval_start: datetime
5 interval_number: int
6
7 def matches_interval(self, encounter_at: datetime, tek_period_hours: int = 24) -> bool:
8 day = int(encounter_at.timestamp() // (tek_period_hours * 3600))
9 return day == self.interval_number

TypeScript

typescriptOne Dark Pro
1export interface RollingProximityId {
2 rpid: Uint8Array;
3 intervalStart: Date;
4 intervalNumber: number;
5}
6
7export function matchesInterval(
8 id: RollingProximityId,
9 encounterAt: Date,
10 tekPeriodHours = 24,
11): boolean {
12 const day = Math.floor(encounterAt.getTime() / (tekPeriodHours * 3600 * 1000));
13 return day === id.intervalNumber;
14}

Why interviewers care

Contact Tracing interviews reward crisp scope, explicit trade-offs, and failure stories—not generic microservice diagrams.

Interview checkpoint

Name one failure story for Problem statement: privacy-preserving exposure notification that proves you understand real outages, not happy-path diagrams.

Key Highlights

  • 180M installed apps
  • Citizen phone → BLE scanner → Exposure server
  • National-scale BLE proximity logging without collecting identity or GPS.
What interviewers want to hear
Lead Problem statement: privacy-preserving exposure notification with 180M installed apps and explicit no-PII/no-GPS boundaries.
Pro tip
Pair 14-day TEK window with on-device HKDF matching narrative for sec-001.

Section Rescue Kit

Buzzwords to use:

TEKRPID

Safe statements:

  • "We never operate a central encounter database in the GAEN model."
  • "Diagnosis keys are signed bundles on CDN, not push payloads with PII."
Design Contact Tracing - System Design | WinJob | WinJob