Design a Resumable Parallel Downloader for Game Client Patches

A game launcher needs to download the next client patch: a set of files listed in a signed, immutable manifest published for each patch version, each with an expected length and a content digest. Design the downloader component that pulls this patch down and hands it to the game only once it's completely and correctly installed.

Scope for this round

• The manifest for a given patch version never changes after publication; a new patch gets a new version and a new manifest.
• The CDN serving patch files supports byte-range requests and returns a version/ETag-like identifier per object.
• The game client must never load a partially-downloaded or corrupted patch, even if the launcher crashes mid-download and is relaunched.
• No specific patch size, player count, or bandwidth target is given — explain how you'd use such numbers if you had them, and state the assumptions you're designing against.

Clarify first

• Can a single file be large enough to need range-splitting, or is file-level parallelism (one worker per file) enough?
• Are digests available per file, per chunk, or only for the whole patch?
• Could the same machine run two launcher instances sharing a disk cache, and if so, who owns an in-progress chunk?
• Does "atomic" mean the whole patch becomes visible at once, or can files be swapped in one at a time as they individually finish?

Part 1 — Planning and fetching pieces

Describe the chunk plan, how many workers run at once, and what a worker checks before it accepts a response as valid for a given chunk. Explain specifically how you prevent silently stitching together bytes that came from two different underlying versions of the same remote file (for example, if the CDN object was replaced mid-download).

What this part should cover: a stable identity for every chunk (file path + version + byte range); bounding concurrent connections, open file handles, and in-flight memory; validating status code, returned byte range, content length, and the object's version/ETag on every response.

Part 2 — Resuming and publishing safely

Explain what's persisted to disk so a relaunch after a crash resumes instead of restarting, and how the launcher transitions from "all files downloaded" to "patch is live" without ever exposing a half-written state to the game process.

What this part should cover: durable, version-bound records of which chunks are verified; safe handling of a chunk file that exists on disk but whose completion was never recorded; the final whole-patch verification and an atomic swap into the location the game actually reads from.