1. Prompt
An analytics team wants to publish daily active users, average order value by region, and trend charts without letting one user's inclusion, removal, or one record materially change a release. Some teammates treat removing names and hashing user IDs as the privacy solution; others want to set epsilon to an arbitrarily tiny number.
Design a differential-privacy release flow. Explain the privacy unit, neighboring datasets, query sensitivity, noise mechanism, epsilon and delta, composition across repeated queries, per-user contribution limits, and accuracy evaluation. State which risks require access control, data minimization, or governance alongside the mechanism.
2. Constraints and clarifications
- First define whether the protected unit is a user, account, device, or event. Multiple events from one user usually belong to one privacy unit.
- Fix the neighboring-dataset definition, such as datasets differing in all records of one user or in one event. Different definitions produce different sensitivities and guarantees.
- Discuss central differential privacy: a trusted internal mechanism accesses raw data and releases noisy results. Anonymization, hashing, and encryption do not automatically provide a differential-privacy guarantee.
- Do not give a “correct epsilon” without a query, data distribution, and threat model. Privacy strength, utility, and user expectations must be chosen together.
3. Core definition: protect output distributions of neighboring datasets
A randomized algorithm M is (epsilon, delta)-differentially private when, for any neighboring datasets D, D', and output event S:
Pr[M(D) in S] <= exp(epsilon) * Pr[M(D') in S] + delta
Even with auxiliary information, this makes it difficult to infer whether a privacy unit is present from one release alone. It does not mean the output contains no sensitive information or that anonymized data cannot be identified. Smaller epsilon generally imposes a stronger privacy constraint but adds more noise; delta is an allowed small failure probability, not an arbitrary error or missingness rate.
The adjacency relation defines what one unit's change means. If one user may contribute at most five orders, a user-level count can be bounded to sensitivity 1, while an order-value sum also needs a bound on each order or the user's total. Otherwise one user can change the result without limit.
4. Mechanisms and reference pseudocode
For a count or bounded sum with sensitivity Delta, the Laplace mechanism releases f(D) + Laplace(Delta / epsilon). For high-dimensional or mean queries requiring an (epsilon, delta) guarantee, a Gaussian mechanism is common, but its calibration depends on sensitivity, delta, and the accounting method.
release_count(users, epsilon, delta, budget):
clipped = cap_each_user_contribution(users, max_contribution=1)
true_count = count_distinct_privacy_units(clipped)
require budget.remaining >= epsilon
noise = sample_laplace(scale=1 / epsilon)
budget.spend(epsilon, delta)
return max(0, round(true_count + noise))
release_mean(records, epsilon, delta, budget):
clipped = cap_each_user_contribution(records, max_rows=K)
clipped_values = clamp_values(clipped, lower=L, upper=U)
sum_release = dp_sum(clipped_values, epsilon_sum, delta_sum)
count_release = dp_count(clipped, epsilon_count, delta_count)
return sum_release / max(count_release, minimum_safe_count)A mean cannot add noise only to the numerator: the denominator also needs protection, and values and per-user contributions must be clipped. Clipping introduces bias and noise introduces variance, so measure interval coverage, relative error, and small-group distortion on simulations or a retained evaluation set.
5. Composition, budgets, and system design
When one privacy unit participates in multiple releases, privacy loss composes. Basic composition adds multiple pure-epsilon guarantees; practical systems can use tighter advanced composition or Rényi DP accounting, but they must standardize the accountant, privacy unit, and delta semantics. Ten filters over the same query still spend budget; aggregation does not make composition disappear.
A budget service should track spent epsilon and delta per privacy unit or dataset, query type, version, and expiry policy. Once exhausted, it should reject, degrade to a coarser result, or return an existing release. Disjoint user partitions can use parallel-composition bounds, but multiple groups containing the same user still require user-level accounting.
Governance should also restrict query permissions, keep audit records, define retention, distinguish exploration from official releases, and enforce minimum group sizes. Differential privacy protects distinguishability of statistical releases; it does not repair unauthorized raw-data access, malicious insiders, business-logic leakage, or a result that should never have been public.
6. Follow-ups and traps
- Why is a hashed ID insufficient? A hash is often still a stable linkable identifier and can be reidentified with external data; it gives no output-distribution guarantee for neighboring datasets.
- Is smaller epsilon always better? No. An epsilon that is too small can make small-group results unusable; choose it with the threat model, user expectations, and error target.
- Why cap user contributions? Without a cap, one highly active user can dominate sensitivity, making noise calibration and the stated guarantee hard to interpret.
- What happens when many segments are released? Every query spends budget; high-dimensional slicing also creates sparse noise and multiplicity concerns. Limit dimensions, preregister queries, and use one accountant.
7. Verification and quality checks
- Property tests: Run the mechanism repeatedly on neighboring datasets and check the output-distribution bound, not only one pair of outputs.
- Utility tests: On a representative evaluation set, measure absolute and relative error, interval coverage, and group-level error differences for counts, sums, and means.
- Budget tests: Simulate repeated queries, concurrent requests, retries, and cache hits to verify that one logical release is charged once and remaining budget cannot be bypassed.
- Governance tests: Verify privacy-unit mapping, clipping, permissions, audit, minimum-group thresholds, and version rollback against the published privacy statement.
8. Interview scoring points
Can define the privacy unit and adjacency
The candidate should state the protected object, user-level or event-level adjacency, and how that choice changes sensitivity and budget.
Can explain mechanism and utility trade-offs
They should distinguish Laplace and Gaussian mechanisms and explain sensitivity, clipping, epsilon, delta, bias, and variance rather than only saying “add random noise.”
Can handle composition and budget governance
They should explain that repeated queries accumulate privacy loss and propose accounting, contribution limits, rejection, or degradation.
Can identify differential privacy boundaries
They should state that differential privacy does not replace access control, data minimization, auditing, or output governance, and give property, utility, and budget tests.