Katkat
Back

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

OpenAISoftware Engineer · Technical Screen
HardSoftware EngineerTechnical ScreenSystem Design

Last updated

System design question about an online devbox service that gives engineers cloud development environments they can create, connect to, stop and resume. It tests lifecycle and API design, fast provisioning, persistent workspace storage, connection routing, isolation of user code, idle cost control and failure handling.

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.

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?

Hints

Hint 1

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 2

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 3

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.

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?