## Design Peer-to-Peer Model Distribution Under a Shared Link Cap Design a system that distributes one large model artifact from a machine that already has it to `N` target machines. Each machine has one network budget: its upload rate plus its download rate may not exceed 10 Gbps at any instant. A target may forward verified chunks before it has received the complete model. Let the model size be `F` gigabits and assume the artifact is immutable during one distribution run. Focus on the lower bound and peer-to-peer design rather than depending on a particular data-center topology. ### Constraints & Assumptions - The seed starts with the only complete copy; all `N` targets need a bit-identical copy. - Upload and download share the same 10 Gbps per-machine budget. - Chunks may travel through several machines, but every received chunk must be verified. - Machines, transfers, and the coordinator may fail and recover. - State whether targets are homogeneous and whether distribution runs can overlap. ### Clarifying Questions to Ask - Is completion time measured when every target has verified the model, or when it can begin serving? - How many targets participate, how large is the model, and may targets join or leave mid-run? - Is there a rack or cross-zone bottleneck in addition to the per-machine cap? - Must the previous model remain available while the new version is downloaded? ### Part 1 — Establish a Defensible Lower Bound Derive lower bounds on completion time from the seed, each target, and the aggregate shared upload/download capacity. Explain which assumptions prevent the bound from being treated as an exact schedule. #### What This Part Should Cover - The seed must emit at least one complete artifact's worth of distinct data. - Every target must receive `F` gigabits. - Each transmitted bit consumes capacity at both an uploader and a downloader. - The effect of chunking, forwarding, and additional topology bottlenecks. ```hint Count capacity at both ends Account for the sender and receiver budgets consumed by each bit before comparing peer-to-peer distribution with repeated seed downloads. ``` ### Part 2 — Design the Peer-to-Peer Data Path Describe chunking, peer discovery, scheduling, and bandwidth allocation. Show how the seed stops being the only data source while peers still respect their combined 10 Gbps budgets. #### What This Part Should Cover - A signed manifest with chunk identifiers, lengths, and content hashes. - A coordinator or gossip mechanism for locating peers that hold each chunk. - Scheduling that spreads scarce chunks and avoids synchronized requests to one peer. - Per-host rate control that divides the shared budget between receiving and forwarding. ```hint Grow the set of useful senders The first chunks should create new uploaders instead of making every target wait behind a complete seed-to-target transfer. ``` ### Part 3 — Complete Safely Under Failure Explain retries, resume behavior, verification, version activation, and observability. Include what happens when a peer advertises a chunk it cannot deliver or sends corrupt bytes. #### What This Part Should Cover - Idempotent chunk writes, partial-download state, timeouts, and alternate peers. - Per-chunk verification followed by whole-artifact verification. - Atomic activation only after the required version is complete. - Progress, bandwidth, rarity, retry, corruption, and straggler signals. ```hint Make peers replaceable Persist completion by chunk identity so a failed connection can resume from another peer without trusting partial bytes. ``` ### What a Strong Answer Covers - A correct lower-bound argument that distinguishes necessary work from an achievable schedule. - A chunked P2P design in which verified receivers become senders and no host exceeds the shared cap. - Explicit integrity, resume, versioning, and straggler behavior. - Trade-offs among chunk size, coordination overhead, fairness, topology awareness, and completion time. ### Follow-up Questions 1. How would the lower bound change if upload and download each had an independent 10 Gbps budget? 2. How would you keep one slow target from reducing useful throughput for the rest of the fleet? 3. When would a tree, gossip protocol, or centralized scheduler be the better control strategy? 4. How would you distribute a new version while the previous model remains in service?