Problem Statement: Training on Private Data Without Moving It
Frames federated learning as a fleet-scale coordination system with a privacy invariant, not a distributed-training variant.
Problem statement
Design a federated learning (FL) platform that trains global machine-learning models across a large fleet of edge devices—smartphones, tablets, in-vehicle units, hospital gateways—while raw training data never leaves the device that owns it. The platform must select eligible devices, distribute the current global model, let each device train locally on its private data, collect model updates (gradients or weight deltas), aggregate them into a new global model, evaluate that model, and release it back to the fleet. It must survive partial and total client dropouts, heterogeneous device compute, adversarial participants, and it must provide a quantifiable privacy guarantee—typically differential privacy, secure aggregation, or both.
This is not ordinary distributed training. In a data-center training job, workers are homogeneous, always on, low-latency, and trusted. In cross-device FL the "workers" are tens of millions of phones that are available only when charging, idle, and on Wi-Fi; they have different data distributions (non-IID), different hardware speeds, and some fraction is malicious. The system therefore separates round progress from two invariants: (1) the privacy invariant—no raw user data leaves the device, and the server learns only a protected, bounded contribution; and (2) the integrity invariant—a new global model is released only after it passes evaluation gates and provenance checks.
Why the problem is distinctive
A normal ML pipeline can retry a failed training step. A federated platform cannot retry a privacy leak: once an update exposing user data is collected or logged, the damage is done. The design therefore treats privacy as a fail-closed invariant. If the differential-privacy accountant cannot bound the contribution, if secure-aggregation masking fails, or if attestation is missing, the platform drops the contribution or aborts the round rather than continuing optimistically.
The problem requires client-side local training and gradient extraction, a central aggregator (FedAvg or advanced), optional secure aggregation or differential privacy, mechanisms for distributing the updated global model back, dropout reliability, thousands of concurrent asynchronous clients, and aggregator-side non-leakage. filecite turn0file4
Public operating baseline versus design assumptions
Public evidence establishes that cross-device FL is production-real. Google reported federated training of next-word prediction models on Gboard, with hundreds of millions of users eligible and secure aggregation in production; the FedAvg algorithm (McMahan et al., 2017) and the Secure Aggregation protocol (Bonawitz et al., 2017) are the canonical references. Apple published Private Federated Learning with on-device local differential privacy. NVIDIA FLARE powered the EXAM study published in Nature Medicine, where 20 hospitals across 4 continents trained a brain-tumor segmentation model without sharing patient data. These are cited context, not requirements for our fictional system.
For capacity planning, this answer explicitly assumes a mature platform with 60 million registered devices, 5 million daily eligible devices, 1 million daily participating updates across 40 concurrent model lines, and a five-times event peak. Unless a number is tied to a citation, it is a stated design assumption, target, budget, or illustrative threshold—not a claim about any company's private architecture.
The four architectural planes
- Device training plane: local trainer, privacy layer (clipping, local noise), delta extraction, quantization and compression, secure upload, energy and thermal guardrails.
- Orchestration plane: model lineage, task configuration, round lifecycle, eligibility and sampling, task distribution, device check-in.
- Aggregation plane: update validation, secure aggregation, differential-privacy noise injection, robust statistics, round checkpointing.
- Governance and learning plane: evaluation harness, release gates, canaries, telemetry, incident evidence, privacy accounting and audit.
A strong interview answer keeps these planes separate. It allows orchestration to degrade without weakening the privacy plane, and it permits the learning plane to improve models without silently changing the validated privacy budget.
Key Highlights
- •Raw data never leaves the device; the server learns only a protected, bounded model contribution.
- •Model round progress is an eventually progressing workflow; privacy and integrity are fail-closed invariants.
- •Public fleet figures from Google, Apple, and NVIDIA provide context; every uncited scale or SLO in this answer is an explicit design assumption.
- •The architecture has four planes: device training, orchestration, aggregation, and governance.
- •A dropped contribution or an aborted round is a successful privacy outcome even when it delays model improvement.
Section Rescue Kit
Buzzwords to use:
Safe statements:
- "I will separate round completion from the privacy invariant: rounds may retry, but privacy must fail closed."
- "Before selecting services, let me define which computations happen on-device, in the aggregator, and only with audit approval."