Online Code Editor — Naive (Shared Process Pool)

Online code editors are increasingly common system design interview questions because they combine real-time collaboration, sandboxed code execution, durable file persistence, and multi-language runtime management into a single problem. Companies like Replit, CodeSandbox, GitHub Codespaces, and StackBlitz ask variants of this question because it directly maps to their core product engineering challenges.

The naive approach uses the simplest possible architecture: a single EditorService backed by PostgreSQL for all data (projects, files, execution output) and a shared pre-warmed process pool for code execution. Files are saved via explicit REST PUT requests — there is no auto-save, no real-time sync, no WebSocket connection. When a user clicks Save, the full file content is sent to EditorService which UPSERTs the file record in PostgreSQL. There is no versioning — the previous content is overwritten and lost.

Code execution uses a shared pool of pre-warmed OS processes. Each process has a pre-loaded language runtime (Python interpreter, Node.js V8 engine, Java JVM, Go runtime). When a user clicks Run, EditorService assigns an available process, writes the code to a temp file in the process sandbox, and executes it. Stdout/stderr is captured and stored in PostgreSQL as an execution record. The client polls GET /api/v1/executions/{id}/output every 2 seconds until the execution completes or times out at 30 seconds.

The shared process pool has two critical problems. First, isolation is process-level only: ulimits cap CPU time (30s) and memory (256MB), but processes share the host OS kernel, filesystem, and network stack. A malicious user could read other users' temp files, scan the internal network, or exhaust the PID table with a fork bomb. Second, resource contention is shared: one user running a CPU-intensive computation (matrix multiplication, cryptocurrency mining) degrades execution performance for all other users sharing the same host.

There is no collaboration capability. Each file has a single editor — if two users open the same file, the last save wins with no conflict detection, no merge, and no notification. There is no cursor sharing, no presence awareness, and no real-time sync. This is acceptable for single-user coding tools (personal projects, homework assignments) but unusable for pair programming or collaborative development.

The polling model for execution output creates wasted bandwidth. At 1K concurrent executions, output polling generates 500 QPS of GET requests, most returning unchanged data. WebSocket streaming (used in V1 and V2) pushes output immediately when available, eliminating 95% of these redundant requests.

This template exists to make the process pool exhaustion and isolation risks visible and measurable. Run the simulation with 200 concurrent execution requests and watch the shared pool exhaust while a single fork bomb crashes the host. Compare with the Container+OT variant (V1) where each session has strict CPU/memory limits via Firecracker microVMs, and the Container+CRDT variant (V2) where CRDT-based collaboration enables real-time multi-user editing.

Interviewers expect candidates to identify the shared process pool as a security risk, propose container-based isolation as the solution, discuss the transition from polling to WebSocket for real-time output, and reason about adding collaborative editing via OT or CRDT.

The naive code editor system is a five-component linear architecture: EditorClient, EditorLB (load balancer), EditorService, CodeDB (PostgreSQL), and ExecWorker (shared process pool). There is no WebSocket gateway, no collaboration service, no container orchestrator, no object storage, and no caching layer.

All traffic arrives at EditorLB (AWS ALB), which distributes requests across EditorService pods using round-robin. The load balancer adds approximately 1.5ms of routing latency and can handle up to 10K RPS — well above the system's actual limits, which are constrained by the process pool. The load balancer is never the bottleneck.

EditorService handles four types of requests. File operations (50% of traffic): users save files via PUT /api/v1/projects/{id}/files/{path} and load files via GET /api/v1/projects/{id}/files. File content is stored as TEXT columns in PostgreSQL — no S3, no versioning, no CDN. Each save overwrites the previous content via UPSERT. Code execution (20% of traffic): users click Run, EditorService reads the file from CodeDB, dispatches to an available process in ExecWorker's pool, and returns a 202 with an execution_id. The client polls for output. Project CRUD (20%): creating and listing projects — standard database operations. Output polling (10%): GET /api/v1/executions/{id}/output — the client polls every 2 seconds for execution results.

CodeDB (PostgreSQL) stores three tables: projects (metadata), files (content as TEXT columns), and executions (output as TEXT columns). A single primary instance with no read replicas handles all reads and writes. At peak: 2,500 file operations/sec + 1,000 execution dispatches/sec + 500 output polls/sec = 4,000 ops/sec. The database connection pool (200 max) can sustain this load but has no headroom for spikes.

ExecWorker is a shared pool of 100 pre-warmed OS processes across 10 worker pods (10 processes each). Each process has a pre-loaded language runtime. Process-level isolation uses ulimits: CPU time limit (30 seconds), memory limit (256MB), file descriptor limit (64), PID limit (32). There is no container boundary — processes share the host kernel, filesystem namespace, and network. A fork bomb bypassing PID limits can crash the host and take down all 10 processes on that pod.

The execution flow is synchronous from the user's perspective: click Run, wait for the poll to return output. There is no streaming, no real-time output, and no interactive stdin support. Long-running programs (web servers, infinite loops) are killed after 30 seconds with no graceful shutdown mechanism.

Vertical scaling for PostgreSQL (upgrade instance size). Horizontal scaling for EditorService (add pods) and ExecWorker (add pods with more processes). Auto-scaling trigger: process pool utilization > 70% for 3 consecutive minutes. The ceiling is approximately 2K-3K concurrent users regardless of pod count, because the shared process pool's isolation model breaks down under adversarial usage. Beyond this ceiling, container isolation is required.

Key metrics to monitor: (1) Process pool utilization — percentage of processes currently executing user code. Alert at 70%, critical at 90%. This is the primary capacity indicator. (2) Execution queue depth — number of Run requests waiting for an available process. Alert if queue depth exceeds 50 (>2.5 second wait). (3) File save latency (p50, p99) — should be under 50ms. Alert at p99 > 200ms indicating database contention. (4) Output poll empty rate — percentage of GET /executions/{id}/output requests returning unchanged data. Expected ~80% waste; useful for justifying migration to WebSocket. (5) PostgreSQL active connections — alert at 70% of max_connections (140/200), critical at 85% (170/200). (6) Process kill rate — frequency of 30-second timeout kills. High kill rate indicates users running long-lived programs (web servers, infinite loops) that exhaust the pool.

At 1K concurrent users: EditorService 4 pods on ECS Fargate (~$250/month), ExecWorker 10 pods (~$625/month), PostgreSQL db.r7g.large (~$200/month), ALB (~$30/month). Total: ~$1,105/month. This is the cheapest variant but breaks down beyond 2K-3K concurrent users due to process pool exhaustion and isolation risks. The V1 Container+OT variant costs approximately $3,500/month but provides kernel-level isolation and real-time collaboration. The V2 Container+CRDT variant costs approximately $15K-20K/month at 100K concurrent sessions but provides the full production feature set.

The naive approach has critical security gaps. Process-level isolation via ulimits cannot prevent: (1) filesystem traversal — user code can read other users' temp files and the host filesystem, (2) network access — user code can scan internal services, make outbound HTTP requests, and exfiltrate data, (3) fork bombs — while PID limits cap process count, the CPU scheduling impact degrades all users on the same host. For internal tools with trusted users, these risks are acceptable with monitoring. For public platforms, container isolation (V1/V2) is mandatory. Additional measures: disable network access in exec processes, mount temp directories with noexec, and run exec processes as a dedicated low-privilege user.

Rolling deployment for EditorService — replace one pod at a time while ALB routes traffic to remaining pods. ExecWorker pods are drained before replacement: wait for all active processes to complete (up to 30 seconds), then terminate. Database migrations run during low-traffic windows. No blue-green needed at this scale — rolling updates provide sufficient safety with minimal complexity.