Design an Online Devbox Service for On-Demand Cloud Development Environments

Design an online devbox service: a platform that gives engineers development environments ("devboxes") that run in the cloud instead of on their laptops. An engineer creates a devbox, connects to it to write, build and run code, stops it when they are done, resumes it later, and eventually deletes it. Only the name of the system was reported, so the description above is the usual scope of such a product. Confirm it with the interviewer, and treat the open points below as clarifying questions. ```hint Separate the machine from the work Decide which parts of a devbox must outlive the machine it runs on. That choice determines what a stop, a resume and a host failure each cost the engineer. ``` ```hint Budget the wait List everything that happens between "create" and the engineer's first command, estimate how long each step takes, and decide which steps can be done before anyone asks. ``` ```hint The box can move A devbox may come back on a different host after a stop or a failure. Decide what a user's connection is addressed to, so that it keeps working when that happens. ``` ### Constraints and Clarifications - No scale, latency or cost targets were given. State the numbers you assume. - A devbox runs whatever code its owner chooses, so it must be isolated from other devboxes and from the platform's own control systems. - A devbox is long-lived and stateful: it holds an engineer's uncommitted work for hours or days. ### Clarifying Questions - Who uses it: one company's engineers, or anyone on the internet? - How many devboxes exist, how many run at the same time, and what sizes (CPU, memory, GPUs) must be offered? - How quickly must a new devbox be usable, and how quickly must a stopped one resume? - What must survive a stop: files only, or also installed packages, running processes and open terminals? - How do engineers connect: a browser-based editor, SSH from their own editor, previews of web servers running inside the devbox? - Is a devbox built from a repository plus an environment definition (base image, setup steps), or does it start as a blank machine? - Should idle devboxes stop automatically to save cost, and what counts as idle? ### What a Strong Answer Covers - Clarifies the users, scale, startup target and what persists, then sizes hosts and storage from stated assumptions - A lifecycle (create, start, stop, delete, failure) with an asynchronous API and a control plane that drives each devbox toward its desired state - Placement onto hosts, image distribution, and prebuilt environments or warm capacity to meet the startup target - Workspace storage that survives stops and host failures, and a connection path that follows the devbox when it moves - Isolation of untrusted code, idle detection for cost, failure handling, and the metrics that show the system is healthy ### Follow-up Questions - A host dies in the middle of the day. What do the engineers on it lose, and how quickly are they working again? - Preparing the environment for a very large repository takes many minutes. How do you make new devboxes start quickly anyway? - Some engineers need GPUs, which are scarce and expensive. What changes in placement, quotas and idle policy? - How do you stop code running in one devbox from reaching other devboxes or the platform's own infrastructure?