Online Code Editor — Collaborative Editing with OT

The online code editor is a compelling system design interview problem because it combines real-time collaboration, sandboxed code execution, and durable file persistence into a single system with fundamentally different scaling characteristics for each concern. Building a platform like Replit or CodeSandbox requires solving problems that span from low-latency collaborative editing (sub-100ms round-trip for keystrokes) to secure untrusted code execution (complete process isolation) to reliable file storage (zero data loss even during container crashes).

At production scale, the system must support 100,000 concurrent editing sessions, each potentially involving multiple collaborators editing the same file simultaneously. The collaborative editing challenge is particularly interesting: when two users type in the same document at the same time, their edits must be merged deterministically so that both clients converge to the same document state. This is the classic distributed consistency problem, and the two leading solutions — Operational Transform (OT) and Conflict-free Replicated Data Types (CRDTs) — each have distinct trade-offs in complexity, memory overhead, and server requirements.

Code execution adds a security dimension that most system design problems lack. Users submit arbitrary code in multiple languages (Python, JavaScript, Java, Go), and the system must execute it without allowing escape from the sandbox. A fork bomb, a network attack, or an attempt to read the host filesystem must all be contained. Container-per-session isolation using Firecracker microVMs or Docker with gVisor provides kernel-level security boundaries, but at the cost of cold start latency (1-2 seconds for container spin-up) and significant aggregate memory consumption at 100K concurrent sessions.

This template models the complete architecture: an API gateway, a load balancer routing REST and WebSocket traffic, an EditorService for project CRUD and file operations, a CollabService implementing Operational Transform, Redis caches for session and document state, PostgreSQL for project metadata, S3 for durable file storage, and a Kafka-backed execution pipeline feeding ContainerWorker pods. The simulation illustrates how OT operation latency varies with concurrent editor count, how container cold start affects the execution experience, and how the separation of EditorService and CollabService enables independent scaling of REST and WebSocket workloads.

The code editor architecture separates three concerns into distinct service boundaries: project management (EditorService), real-time collaboration (CollabService), and code execution (ContainerWorker). This separation is driven by fundamentally different scaling dimensions — EditorService scales with REST request volume, CollabService scales with concurrent WebSocket connections, and ContainerWorker scales with active execution sessions.

When a user opens a project, the EditorClient connects through the API Gateway and MainLB. The EditorService loads project metadata from ProjectDB (PostgreSQL) and file contents from FileStorage (S3), caching active session state in SessionCache (Redis). If the project has other active collaborators, the client also establishes a WebSocket connection to CollabService, which sends the current document state from DocCache (Redis) along with any recent operations the client needs to replay for catch-up.

Real-time collaboration is handled entirely by CollabService using Operational Transform. Each keystroke generates an OT operation (insert, delete, or retain) that is sent to CollabService via WebSocket. The service transforms the operation against any concurrent edits from other users — this is the core OT algorithm that ensures all clients converge to the same document state regardless of operation ordering. The transformed operation is applied to the canonical document in DocCache and broadcast to all session participants. The target latency for this full round-trip is under 100ms, which requires DocCache reads and writes to complete in under 10ms.

Code execution follows an asynchronous pipeline. When the user clicks "Run," EditorService publishes an execution request to ExecStream (Kafka). ContainerWorker consumes the request, spins up an isolated Firecracker microVM or Docker container with strict resource limits (1 CPU core, 512MB RAM, restricted network), mounts the project files from S3, and executes the code. Stdout and stderr stream back to the client in real-time through the CollabService WebSocket connection. Containers are torn down after execution completes or after a five-minute idle timeout.

File persistence uses a dual-write strategy: auto-save every five seconds flushes the canonical document state from DocCache to S3, and the file version is recorded in ProjectDB. S3 versioning provides built-in file history without custom implementation, enabling undo and version browsing. This ensures that even if a container crashes or a session drops, the user's work is preserved up to the last auto-save checkpoint.