Design a Cloud IDE That Edits and Runs Code in Browser-Accessible Workspaces

Design a cloud IDE: a service where developers open a project in the browser, edit its files, run the code, and use a terminal, while the files and the environment that executes the code live on the service's servers instead of on the developer's own machine. This came up as the system design round of an onsite loop for a software engineer role, and the prompt was only "cloud IDE", so the scope is yours to settle with the interviewer. Aim for depth, not breadth. Once the high-level design is on the board, expect to be pushed on the parts that are specific to this product: how a workspace is created, stopped and resumed, how untrusted code is kept from harming other users, and how keystrokes, terminal output and a running app's preview travel between the browser and the workspace. ```hint Split the editor from the machine Separate what has to feel instant on every keystroke from what actually runs the user's code, and decide which of the two needs strong isolation. ``` ```hint Price an idle workspace Estimate what it costs to keep a workspace's compute running while its owner is away, and let that number shape how workspaces start, stop and resume. ``` ### Clarifying Questions - What does a workspace hold: single-file snippets, or full repositories with dependencies and long-running development servers? - Can anyone on the internet sign up and run arbitrary code, or is this an internal tool for one company's engineers? - Which languages and runtimes must be supported, and can users install packages or bring their own container image? - Is real-time collaborative editing (several people in the same file) in scope? - How long must a workspace persist, and what should happen to it while its owner is idle? - What scale should the design target: registered users, concurrently active workspaces, and CPU and memory per workspace? - Are Git integration, debugging, language features such as autocomplete, and previewing a running web app required? ### What a Strong Answer Covers - Requirements and scale assumptions, including which workloads the design supports and which it excludes - A split between a control plane (accounts, workspace metadata, scheduling) and a data plane (the hosts that run workspaces) - The workspace lifecycle: provisioning, cold-start latency, idle shutdown, and resuming with files and state intact - Isolation of untrusted code: the sandboxing technology, resource limits, network egress controls and abuse prevention - Where workspace files live, how they are made durable, and how the editor reads and writes them - The real-time channels between browser and workspace: file edits, terminal streams, language services and app previews - Scheduling and packing workspaces onto hosts, and scaling both planes - Failure handling and observability: host loss, stuck workspaces, noisy neighbors, and what the user experiences in each case ### Follow-up Questions - The host running many active workspaces dies. What does each user see, and what, if anything, is lost? - How would you get a stopped workspace back to "ready to type" in a few seconds? - How do you stop users from mining cryptocurrency or attacking other machines from their workspaces? - How would you add real-time collaborative editing for two people working in the same file?