One software release is 2 GB. How do you deliver it to 100 million devices?

Interview question. Your company ships a 2 GB signed desktop application update to 100 million devices worldwide. The first launch overloaded origin storage and forced customers to restart downloads. Design content distribution, resumability, release control and client verification so the next rollout is fast without making a compromised mirror a path to malicious code.

The capacity calculation should happen before drawing boxes. Two gigabytes multiplied by 100 million devices is 200 petabytes of transfer, using decimal units. If everyone downloaded the full package during one day, the average delivery rate would be about 2.31 terabytes per second across the distribution fleet, before retries and protocol overhead. Peak demand may be far higher. This is not an application-server endpoint you solve by adding a bigger load balancer. Most bytes need to come from geographically distributed caches or peers under a verified content protocol.

The obvious architecture starts with immutable, content-addressed package objects in durable object storage, delivered through multiple CDN regions. A small update metadata service tells clients what version is available, what platform and architecture it applies to, and which artifact hashes and sizes to expect. Clients download the bytes from a nearby delivery location, not from the metadata API. Origin shielding and warmup can reduce how often a newly published package reaches the object store. But the first global rollout still creates real edge-fill traffic, so coordinate release timing and warm likely regions ahead of demand.

A major cost lever is not downloading unchanged bytes. If a carefully engineered binary delta averages 100 MB instead of 2 GB, the theoretical total is 10 PB rather than 200 PB, a twentyfold reduction in payload. Deltas are conditional, though. A client with an unexpected base version, damaged installation or unsupported patch format must be able to fetch a complete verified artifact. Patching also consumes CPU, memory and temporary disk. A slow patch on a low-end laptop can be worse for users than a somewhat larger download. Compare complete transfer, patch success, verification and install time, not bytes alone.

Now the unreliable-network case. A commuter downloads 1.7 GB and loses Wi-Fi. A client that always restarts at byte zero wastes almost an entire package. HTTP range requests can fetch missing ranges from an immutable resource. Persist a chunk bitmap or verified byte ranges and request only those not already stored. Use a stable content identifier and validators when resuming, so bytes from two different builds do not become one corrupted installer. A final strong hash check verifies the assembled artifact before installation. The CDN's exact range caching behavior depends on vendor support and response headers. Treat it as a capability to test, not an assumption that every edge caches every possible range.

Security is the other half of the problem. HTTPS protects a transport connection, but delivery infrastructure should not alone decide what code clients install. A mirror can be misconfigured or compromised. Sign release metadata with appropriately protected keys and let clients verify the expected artifact digest, target identity and approved version. The Update Framework, or TUF, separates root trust, target descriptions, snapshots and freshness metadata to help defend against rollback, freeze and mix-and-match attacks. Adopting that design is more precise than telling a client to trust whatever JSON arrives from the closest CDN.

An apparently easy rollback also needs care. If version 42 is faulty, product operators may want devices back on version 41. But a client that blindly accepts any lower version is vulnerable to a network attacker repeatedly serving an old insecure release. Define a signed emergency rollback authorization or recovery policy that reconciles operational rollback with anti-rollback protections. Treat artifact authenticity and suitability for this device as separate checks. A correctly signed binary for another operating system is not necessarily a valid update here.

Rollout policy should avoid synchronized demand. Start with a small canary population, evaluate download failures, install success, launch crashes and user-visible regressions, then expand by geography and device class. Add randomized polling intervals and backoff for metadata checks. Limit bandwidth per origin and per edge path where the infrastructure supports it. Release waves reduce blast radius as well as peak bandwidth, which is useful when the failure is a broken installer rather than a capacity shortage.

Consider the difference between downloaded and installed. A device may finish transferring bytes and still fail integrity verification, run out of disk during patching, or fail to restart the application. Track the release state machine: offered, downloaded, verified, staged, installed, booted and healthy. It is tempting to stop measuring at HTTP 200, but that metric does not establish successful delivery of a working product.

The final architecture is deliberately boring in one respect. The large files are immutable, caches can reuse them, and clients verify exact bytes. The sophisticated work is in scheduling, metadata trust, safe recovery and staged rollout. A Staff or Principal candidate should be able to defend the capacity math, recovery behavior, security contract and rollout controls together, because an update distributed perfectly to a hundred million broken devices is still a failed system.