Online Code Editor — Container + OT Collaboration

The container-per-session with Operational Transform approach represents the industry-standard architecture for production online code editors. It solves the two fundamental problems with the naive architecture: the lack of execution isolation and the absence of real-time collaboration.

The key insight is separating two fundamentally different concerns: code execution isolation and collaborative editing. Container-per-session provides kernel-level isolation by running each user's code in a dedicated Firecracker microVM or Docker container with strict resource limits (1 vCPU, 512MB RAM, restricted network). This eliminates the shared process pool's security risks — a fork bomb or malicious program cannot affect other users because the microVM's kernel enforces isolation independently of the host.

Operational Transform (OT) enables real-time collaborative editing where multiple users edit the same file simultaneously. Each keystroke generates an OT operation (insert, delete, retain) sent to CollabService via WebSocket. CollabService transforms the operation against any concurrent edits from other users using the OT algorithm, applies the transformed operation to the canonical document state in DocCache (Redis), and broadcasts it to all connected session participants. The transformation ensures all clients converge to the same document state despite concurrent, conflicting edits.

The architecture separates REST operations from real-time WebSocket operations. EditorService handles project CRUD, file save/load, and execution triggers via standard REST endpoints. CollabService handles WebSocket connections for OT operations. These services have fundamentally different scaling characteristics: EditorService scales with request volume (throughput-bound), while CollabService scales with concurrent connections (connection-bound). Separating them allows independent scaling — 8 EditorService pods for 80K RPS versus 10 CollabService pods for 100K concurrent WebSocket connections.

Kafka decouples execution requests from container lifecycle management. When a user clicks Run, EditorService publishes an execution request to the exec-request topic. ContainerWorker consumes the request, allocates a container, mounts project files from S3, executes the code, and streams stdout/stderr back to the client via CollabService's WebSocket connection. If ContainerWorker is at capacity, requests queue in Kafka with backpressure rather than failing immediately.

The primary trade-off is operational complexity: 10 components instead of 5, Kafka cluster management, Redis cluster monitoring, WebSocket connection management, and container orchestration. The OT algorithm also requires CollabService as a central coordination point — if CollabService goes down, collaborative editing stops (though solo editing can continue with local state). The V2 CRDT variant addresses this by replacing OT with a conflict-free replicated data type that does not require central coordination.

Interviewers expect candidates to explain why container-per-session provides better isolation than shared processes, describe the OT algorithm for conflict resolution, discuss Kafka's role in decoupling execution from container management, and reason about the separation of REST and WebSocket services.

The container-per-session with OT architecture uses ten main components organized into four layers: edge (EditorClient, ApiGateway, MainLB), application services (EditorService, CollabService), data stores (SessionCache, DocCache, ProjectDB, FileStorage), and execution pipeline (ExecStream/Kafka, ContainerWorker).

The REST path handles file operations and execution triggers. Requests flow through ApiGateway (authentication, rate limiting at 60K RPS) to MainLB (AWS ALB, content-based routing) to EditorService (8 pods, 80 threads each). EditorService reads/writes project metadata from ProjectDB (PostgreSQL), file content from FileStorage (S3), and session state from SessionCache (Redis). For code execution, EditorService publishes a request to ExecStream (Kafka) and returns 202 Accepted immediately.

The WebSocket path handles real-time collaboration. EditorClient establishes a WebSocket connection to CollabService (10 pods, 100 threads each = 100K concurrent connections). Each keystroke generates an OT operation sent via WebSocket. CollabService reads the canonical document state from DocCache (Redis), transforms the incoming operation against concurrent edits, writes the transformed state back to DocCache, and broadcasts the result to all session participants. Round-trip latency target: under 100ms.

The execution pipeline is asynchronous. ExecStream (Kafka, 16 partitions) carries execution requests from EditorService to ContainerWorker (50 workers). ContainerWorker spins up Firecracker microVMs with strict resource limits, mounts project files from FileStorage (S3), executes code, and streams stdout/stderr back to the client via CollabService's WebSocket connection. Containers are torn down after execution completion or 5-minute idle timeout.

Data persistence uses a three-tier strategy. ProjectDB (PostgreSQL) stores project metadata and file version history with strong consistency. FileStorage (S3) stores file content with 99.999999999% durability and built-in versioning. SessionCache and DocCache (Redis) provide sub-millisecond access to active session state and document state respectively.

Horizontal scaling is independent per component. EditorService scales with REST request volume. CollabService scales with concurrent WebSocket connections. Kafka scales via partition count. ContainerWorker scales with concurrent execution demand. Redis scales by adding nodes to the cluster.