Design an Online Development Box

Design an online development box: a remote workspace where a developer can edit files, run development tools, and reconnect to the same project from a client. ### Constraints & Assumptions - The source names an online devbox system-design task without supplying a detailed product specification. - **Practice scope:** authenticated users create workspaces from an approved environment image and project source, connect through a browser or compatible editor, run terminal commands, stop the workspace, and resume later with project files preserved. - Treat code executed inside a workspace as untrusted relative to other users and the platform's control plane. - No concurrent-user count, startup target, hardware profile, availability target, or geographic requirement is supplied. Identify how these would influence the design instead of inventing numeric targets. - Collaboration by multiple simultaneous editors, specialized hardware, and arbitrary public service hosting are optional extensions rather than core requirements. ### Clarifying Questions to Ask - Which files and installed tools must persist across a stop, restart, or machine failure? - Does a workspace need root-like privileges, custom containers, outbound network access, or credentials for private repositories? - What does stopping mean for running processes, unsaved editor buffers, and active connections? - Are fast cold starts more important than minimizing idle compute cost? - Must reconnecting clients reach the same running process, or is restoring files into a fresh runtime sufficient? ### Part 1 — Create and Connect to a Workspace Describe the control plane, runtime placement, connection routing, and workspace records. Walk through creation from an image and project source to an authenticated editor or terminal connection. #### What This Part Should Cover - Workspace identity, desired state, owner authorization, and runtime identity. - An asynchronous provisioning lifecycle with idempotent retries. - Routing a connection to the current authorized runtime without exposing platform credentials. ### Part 2 — Isolate Execution and Preserve Work Explain tenant isolation, resource and network controls, secret delivery, persistent project storage, and recovery after runtime failure. #### What This Part Should Cover - A trust boundary suitable for untrusted development code. - Separation of persistent project files from disposable runtime state. - The difference between durable file recovery and resuming arbitrary process memory. ### Part 3 — Stop, Resume, and Operate Efficiently Explain idle stopping, image or environment changes, node failures, and the trade-off between startup speed and idle cost. #### What This Part Should Cover - Lifecycle transitions that do not allow an old runtime and a replacement to corrupt one workspace. - Warm capacity or prebuilt environments without cross-user data leakage. - Observability for provisioning failures, connection failures, storage problems, and resource abuse. ```hint Separate the workspace from its machine A user expects project files to survive even when the host running their terminal disappears. Identify which records and storage outlive that host. ``` ### What a Strong Answer Covers - A complete workspace lifecycle from creation through reconnection and deletion. - Isolation and authorization on both management actions and live connections. - Explicit file-durability and process-resume guarantees. - A practical strategy for cold starts, idle resources, and recovery that matches the still-unspecified scale. ### Follow-up Questions - How would you safely preview a web server running inside a workspace without exposing another user's service? - What happens if a resume request arrives while an idle-stop operation is still in progress? - How would you update the environment image while preserving a user's project and making incompatibilities visible?