# Design a collaborative online IDE: system design interview question

> Simultaneous edits and tool writes share files, while terminals and untrusted code require clear state rules and strong execution boundaries.

Source: https://sysround.com/questions/design-collaborative-online-ide
Updated: 2026-11-05


Difficulty: hard. Levels: Senior, Staff+.

## How the interviewer opens it

"Design a shared coding workspace where collaborators edit files, use terminals, and run code. Explain how the service synchronizes workspace state and isolates code execution."

## What to clarify first

- Files and workspace size
- Scale
- Read and write mix
- Terminal traffic
- Latency
- Consistency and availability
- Durability and recovery
- Execution limits and trust
- Access and location
- Excluded features

## Scope of a strong answer

Core requirements:

- Edit shared text files at the same time
- Create, rename, and delete workspace files
- Share terminals and run code in an isolated workspace
- Recover durable workspace state after a connection or runtime failure

Usually out of scope:

- Git repository hosting
- Debugger features and language servers
- Public application hosting
- Full offline work

## What interviewers probe

### Edits from several collaborators

Collaborators change overlapping text from different document versions. File renames and deletions also change the meaning of later edits.

### Files seen by editors and commands

Editors and tools change the same files through different interfaces. A file copy can erase tool changes before the service notices them.

### Code from unknown users

User code can attack the host, exhaust shared resources, or steal credentials. Workspace access can also change during an active session.

### Connection loss and runtime failure

Document edits need durable replay, but terminal input causes external effects. A reconnect must not create another runtime or repeat a command.

## Common mistakes

- The design replaces entire files and loses concurrent edits.
- The design checks file versions without preventing tool writes between the check and replacement.
- The design promises fresh files for Run but leaves shared terminal behavior undefined.
- The design trusts a container to isolate hostile code without a threat model.
- The design acknowledges edits before durable storage or repeats uncertain terminal input after reconnect.
- The design estimates connection traffic but ignores runtime CPU and memory costs.

## The bar by level

- **Senior:** Defines durable edit acknowledgments, duplicate suppression, and the distinct guarantees for Run and terminal input. Prevents file replacement from erasing unimported tool changes. Handles terminal reconnects and runtime replacement. Selects a credible sandbox and calculates runtime capacity.
- **Staff+:** Defines ownership fences across coordinators, runtimes, and durable state. Proves file preservation across concurrent writes, open handles, and failed imports. Tests access revocation and uncertain command outcomes. Balances runtime capacity, start latency, and storage limits. Assess regional recovery only if the interviewer asks that follow-up.

Practice this question with an AI interviewer: https://sysround.com/practice/new?problem=collaborative-coding-environment


---
SysRound (https://sysround.com) is an AI practice tool for system design interviews. It has a voice or typed AI interviewer and a shared whiteboard. At the end, you get feedback on each skill and a model answer. The AI feedback can be wrong.