How Would You Design an Online Code Editor (like Repl.it)?
System design guide to building a Repl.it-style online code editor: CRDTs, sandboxed execution, and persistence.
Expected Interview Answer
Design an online code editor as three layers: a collaborative document layer using operational transformation or CRDTs for real-time multi-cursor editing, a sandboxed execution layer that runs untrusted user code in isolated containers, and a workspace/file-persistence layer that snapshots the project so it survives disconnects and restarts.
The editor front end sends every keystroke as an operation (insert, delete, position) over a WebSocket to a collaboration service, which applies a CRDT or OT algorithm so concurrent edits from multiple users converge to the same document state regardless of arrival order, then broadcasts the transformed operation to other connected clients. When the user runs code, the request goes to an execution service that spins up a short-lived, resource-limited container (CPU/memory/time quotas, no network access by default, ephemeral filesystem) seeded with the current file snapshot, executes the code, and streams stdout/stderr back over the same WebSocket. Containers are pooled and pre-warmed to cut cold-start latency, and are destroyed after each run to prevent state leaking between users. The workspace itself (files, folder structure) is periodically snapshotted to durable storage (object store plus a metadata DB) so a user can close their laptop and resume exactly where they left off on any device, and version history can be reconstructed from the operation log.
- CRDTs/OT let many users edit the same file concurrently without lock contention or conflicting edits
- Sandboxed, resource-limited containers isolate untrusted code execution from the host and other users
- Pre-warmed container pools cut the run-button latency that would otherwise hurt UX
- Periodic snapshotting plus an operation log gives durability and replayable version history
AI Mentor Explanation
Designing an online code editor is like a scorebook that multiple scorers update simultaneously from different ends of the ground, where each entry (keystroke) is merged automatically so the book stays consistent no matter which scorer wrote first. Running the code is like sending a specific delivery to a practice net cordoned off from the main pitch, so a wild throw cannot hit anyone else, and the net is cleared after each use. The full scorebook is saved to the pavilion archive periodically so play can resume exactly where it left off even if a scorer steps away. That merge-on-edit plus isolated-execution model is exactly how an online code editor works.
Step-by-Step Explanation
Step 1
Stream edits as operations
Every keystroke is sent as an insert/delete operation over a WebSocket to a collaboration service.
Step 2
Merge with CRDT/OT
The collaboration service applies a CRDT or operational transform so concurrent edits converge regardless of arrival order, then broadcasts to other clients.
Step 3
Execute in a sandbox
On run, code executes in a short-lived, resource-limited, network-restricted container seeded from the current file snapshot.
Step 4
Persist and snapshot
The workspace is periodically snapshotted to durable storage so users can resume on any device and reconstruct version history.
What Interviewer Expects
- Names CRDT or operational transformation as the mechanism for concurrent editing
- Describes container-based sandboxing with resource and network limits for untrusted code execution
- Discusses cold-start latency and pre-warmed pools for the run button
- Explains persistence strategy so sessions survive disconnects and restarts
Common Mistakes
- Using a simple last-write-wins strategy for concurrent edits instead of OT/CRDT
- Running untrusted user code without sandboxing or resource limits
- Ignoring cold-start latency of spinning up a fresh container per run
- Forgetting to persist workspace state, losing work on disconnect
Best Answer (HR Friendly)
“I would build the editor so every keystroke is treated as a small operation that gets merged automatically when multiple people type at once, so everyone always sees the same consistent file. When someone runs code, it executes inside a locked-down, temporary sandbox with limited resources so it cannot affect anyone else, and the whole project is saved regularly so people can pick up right where they left off.”
Code Example
def run_code(workspace_id, file_snapshot, language):
container = container_pool.acquire(language, prewarmed=True)
container.set_limits(cpu_seconds=5, memory_mb=256, network=False)
container.write_files(file_snapshot)
result = container.exec(timeout_seconds=5)
stream_output(workspace_id, result.stdout, result.stderr)
container.destroy() # never reused across users
return result.exit_codeFollow-up Questions
- How does a CRDT differ from operational transformation for collaborative editing?
- How would you defend the execution sandbox against container escape or resource exhaustion attacks?
- How would you implement undo/redo correctly in a multi-user collaborative document?
- How would you scale execution for compute-heavy languages like compiled C++ versus a simple script?
MCQ Practice
1. Why do collaborative code editors use CRDTs or operational transformation?
CRDTs and OT resolve concurrent, out-of-order edits so every client ends up with the same document state.
2. Why is user code executed inside a resource-limited, isolated container?
Untrusted code must be sandboxed with CPU/memory/time/network limits so it cannot compromise the host or other tenants.
3. Why pre-warm a pool of execution containers?
Pre-warmed containers avoid the delay of provisioning a fresh sandbox on every run, improving perceived responsiveness.
Flash Cards
How do multiple users edit the same file concurrently? — Edits are sent as operations merged via a CRDT or operational transformation algorithm.
How is untrusted user code executed safely? — In a short-lived, resource-limited, network-restricted container destroyed after each run.
Why pre-warm containers? — To reduce cold-start latency when a user clicks run.
How does the editor survive a disconnect? — The workspace is periodically snapshotted to durable storage, letting users resume on any device.