How would you design a privacy-preserving product telemetry and analytics platform?

1. Prompt

A company wants to understand feature usage, crash categories by version, and region-level performance distributions for a desktop client. It has about 20 million active devices per day, with at most 200 telemetry events per device. Product teams need aggregate trends within 24 hours, while privacy teams prohibit reconstructable user behavior timelines.

Design a privacy-preserving telemetry and analytics platform. Cover client collection boundaries, event format, anonymization or local randomization, central differential privacy, user-level contribution limits, budget and query APIs, reliability, deletion requests, permissions, and verification. State clearly which problems cannot be solved by hashing an ID.

2. Constraints and clarifications

• Prefer a user or device as the privacy unit rather than treating every event as an independent person; explain shared devices and multi-device users.
• Collect only registered event names, version, coarse region, performance buckets, and required error categories. Do not collect raw URLs, free text, full IP addresses, precise location, or content payloads.
• Release statistics in windows of at least 24 hours with small-group suppression, a differential-privacy budget, and traceable query audit.
• Loss and delay are acceptable, but retries, caches, and replicas must not amplify one user's contribution without bound.

3. High-level architecture and data flow

The client SDK applies an event allowlist, field clipping, value bounds, and local sampling before writing versioned batches to a telemetry queue. The ingestion gateway verifies signatures, size, time window, and rate without using an account token as an analytics key. Stream processing performs user-level deduplication, contribution caps, window aggregation, and anomaly filtering. A short-lived raw buffer has a strict TTL; the long-term store keeps only protected aggregate intermediates.

client SDK
  -> schema/allowlist + local sampling + coarse buckets
  -> encrypted batch with rotating upload token
  -> ingestion gateway (auth, size, rate, replay checks)
  -> stream buffer
  -> privacy transform (user contribution cap, clipping, optional local noise)
  -> aggregate store
  -> DP query service (budget, minimum group, audit)
  -> dashboards and export API

Local randomization protects individual reports from an untrusted collector but reduces accuracy; central differential privacy makes user-level budget accounting easier for a trusted internal aggregator. A hybrid must define the threat model and guarantee at each layer; simply adding noises does not justify a stronger claim.

4. Data model, minimization, and deduplication

An event contains event_type, client version, coarse region, a performance bucket, an event-time bucket, and protocol version. An upload batch has a random batch ID, expiry, and signature. The server uses a short-lived internal key for idempotency and never writes a stable user identifier to the long-term analytics table.

Repeated events from one user for one feature in a window follow a preregistered rule, such as at most one contribution per user per feature per day. The cap must be enforced at user level, not only per machine or batch; otherwise an attacker can split batches to bypass it. Crash stacks, error text, and URLs should be bucketed or dropped on the client so free text cannot become a hidden identifier.

A deletion request needs an executable scope. If the long-term store contains only irreversible differentially private aggregates, one user usually cannot be removed exactly from a published aggregate. The system should still delete short-lived raw buffers, stop future collection, and document the irreversible boundary of aggregate releases.

5. Privacy budgets, reliability, and query APIs

The query service tracks an epsilon/delta budget by privacy unit, dataset, and time window. Each official query checks budget, minimum group size, and allowed dimensions, then produces a noisy result from a versioned aggregate table and records an audit entry. A retry of the same logical query must return an idempotent result or be charged once; adding a filter dimension may spend additional budget.

Uploads use at-least-once delivery. Client batches can retry, the gateway deduplicates by a batch token, and stream processing deduplicates by user and time bucket while isolating unconfirmed late events. Loss, delay, and sampling rate belong in data-quality metrics; otherwise a dashboard drop can be misread as a product behavior change.

At 20 million devices and at most 200 events per device per day, the theoretical upper bound is 4 billion events per day. The design should use sampling, batch compression, and partitioned storage with headroom for version rollouts, crash storms, and replay. The query layer must limit high-cardinality slices, concurrent exports, and cross-window joins so budget and compute cannot be exhausted together.

6. Follow-ups and traps

• Is a hashed device ID anonymous? A stable hash remains linkable across events and may be reidentified with external data; prefer short-lived tokens, coarse fields, and user-level aggregation.
• How do client and central noise differ? The local model reduces trust in the collector but has higher variance; the central model simplifies budget and query management if access to the aggregator and raw buffer is controlled.
• How do you handle a crash storm? Client sampling and rate limits protect users and ingress, the gateway isolates bad versions, and queue backpressure and degraded queries protect downstream systems; merely scaling the database is insufficient.
• Can the platform answer any analysis question? No. Allowlisted metrics, minimum groups, budget accounting, and dimension limits are product contracts; exploratory requests need approval and a separate budget.

7. Verification and operating metrics

• Privacy properties: Test contribution caps, noise calibration, budget composition, and query rejection on neighboring user datasets; audit parameters for every release version.
• Data quality: Monitor sampling rate, device coverage, duplicate rate, lateness, loss, version distribution, and window completeness, and reconcile against controlled synthetic data.
• Reliability: Inject failures into ingress, queues, aggregators, and the budget service to verify idempotent retry, backpressure, quarantine, recovery points, and no raw-data leakage.
• Abuse controls: Test high-dimensional queries, concurrent exports, exhausted budgets, permission escalation, batch replay, and free-text injection, confirming a rejection or degradation path for each.

8. Interview scoring points

Can draw privacy boundaries and data flow

The candidate should state what the client, gateway, short-lived buffer, aggregation layer, and query layer trust, retain, and delete.

Can implement user-level contribution control

They should cover user/window deduplication, contribution caps, clipping, batch idempotency, and late events rather than only writing “anonymize it.”

Can design budget and reliability together

They should include epsilon/delta accounting, charge-once retries, minimum groups, query dimension limits, backpressure, and failure recovery.

Can give quantitative verification

They should use the 4-billion-events-per-day upper bound and propose privacy, data-quality, reliability, and abuse tests instead of only listing components.