Katkat
Back

Design a Version-Aware Package Download Service That Fetches Missing Dependencies

NVIDIASoftware Engineer · Onsite
MediumSoftware EngineerOnsiteSystem Design

Last updated

Design a download service for versioned software packages that, when a user requests a version such as Python 2.7, also fetches every dependency missing from their machine. It tests dependency resolution with version ranges, conflicts with already-installed packages, reliable downloads and installs, and serving large artifacts at scale.

Design a download service for versioned software packages. A user asks for a specific version of a package, for example Python 2.7. Some of the packages that this version depends on are missing from the user's machine, and the service must find and download those as well, so that the requested version can be installed and run.

The part that is hardest to explain well, and the one to make most precise, is the dependency lookup: how the service decides which version of each dependency is needed.

Constraints and Clarifications

  • Not given: the number of packages and versions, package sizes, the number of client machines, how dependencies declare versions, and whether two versions of one package can be installed side by side. Ask, or state your assumptions.

Clarifying Questions

  • Do dependencies name exact versions, or ranges such as "at least 1.2 and below 2.0"?
  • Can two versions of the same package be installed on one machine at the same time?
  • Does the client tell the service what is already installed, or does the client do the resolution itself using metadata from the service?
  • Are packages platform-specific (operating system, CPU architecture), so that one version has several builds?
  • Can a published version ever be changed or withdrawn?
  • How many machines download, how large are packages, and do many machines in one location fetch the same package at once?

Hints

Hint 1

Metadata versus bytes: Deciding what to fetch needs only small descriptions of packages and their dependencies, while the packages themselves can be large. Consider storing and serving the two differently.

Hint 2

Ranges, not names: A dependency usually names a range of acceptable versions rather than one version. Walk through a case where the version already on the machine does not satisfy what the new package needs.

Follow-up questions

  • Two packages the user wants need incompatible versions of the same library. What does the service do?
  • A published version turns out to be broken. How do you withdraw it without breaking machines that already depend on it?
  • Thousands of machines in one data center request the same large package within a minute. How do you protect the origin?
  • How do you guarantee that a machine set up months from now gets exactly the same versions as one set up today?