Designing Online Code Editor | System Design

Designing an Online Code Editor means building a platform where users can write, run, and save code directly from the browser without installing anything locally. In an interview, the main focus is on secure code execution, low-latency results, and handling many users running code at the same time.

• Users should be able to write, edit, save, and execute code in multiple programming languages.
• The system should execute untrusted code safely in isolated environments and return output or errors quickly.

1. Problem Statement

We need to design an Online Code Editor where users can write and execute code directly from a web browser. The system should support multiple languages and run each program securely without affecting other users or the underlying servers.

• Users should be able to create, edit, save, and run code and receive execution results in real time.
• The system should isolate every execution, enforce CPU/memory/time limits, and handle a large number of concurrent code submissions.

2. System Requirements

Before designing the system, we need to identify its functional and non-functional requirements. These requirements define what the Online Code Editor should do and how well it should perform.

Functional Requirements

• Users should be able to create, edit, save, and delete code files.
• The editor should support multiple programming languages such as C++, Java, Python, and JavaScript.
• Users should be able to compile and execute their code from the browser.
• The system should display program output, compilation errors, and runtime errors.
• Users should be able to provide custom input to their programs.
• The system should store code and allow users to reopen their saved projects.
• Each code execution should run inside an isolated environment.

Non-Functional Requirements

• Low Latency: Code execution results should be returned as quickly as possible.
• Scalability: The system should support a large number of concurrent users and code executions.
• Security: Untrusted user code must not access other users' data or the host system.
• Availability: The editor and execution service should remain available with minimal downtime.
• Reliability: Code, execution results, and saved projects should not be lost unexpectedly.
• Resource Isolation: Every execution should have limits on CPU, memory, execution time, and network access.

3. Capacity Estimation

Before designing the architecture, we estimate the expected users, code submissions, execution load, and storage. These estimates help us choose the right execution servers, queues, databases, and scaling strategy.

Assumptions

3.1 Code Execution Requests

Assume the system processes around 20 million code executions per day.

Execution RPS = 20 Million / 86,400
≈ 231 executions/second

During contests, interviews, or peak hours, traffic can be much higher.

Peak Execution RPS ≈ 5 × Average
≈ 1,150 executions/second

3.2 Storage Estimation

Assume each saved code file requires around 50 KB.

Daily Storage = 2 Million Users × 50 KB
≈ 100 GB/day

For 30 days:

Monthly Storage ≈ 3 TB/month

This excludes execution logs, project files, and backups.

3.3 Execution Server Estimation

Assume one execution server can safely handle around 100 concurrent sandboxed executions.

Servers Required = 20,000 / 100
≈ 200 Execution Servers

Additional servers should be kept for failures and sudden traffic spikes.

3.4 Resource Usage

Each execution should have predefined limits such as:

• CPU: Limited CPU cores or CPU time.
• Memory: Fixed memory limit per execution.
• Execution Time: Programs should be terminated after a timeout.
• Storage: Temporary disk space should be limited.
• Network: Internet access should normally be restricted inside the execution sandbox.

4. High Level Design

The High-Level Design (HLD) describes the overall architecture of the Online Code Editor and explains how different components work together to provide secure, scalable, and low-latency code execution.

Core Components

After the diagram, explain each component one by one.

• Client: Represents the Online Code Editor running in a web browser or mobile application. It allows users to write and edit code, manage projects, run programs, provide input, and view execution results.
• API Gateway: Acts as the single entry point for client requests. It handles authentication, request validation, routing, and rate limiting before forwarding requests to the appropriate backend services.
• Load Balancer: Distributes requests across multiple instances of backend services to prevent overload and improve availability and scalability.
• Code Editor Service: Manages code editing-related operations, including creating, updating, retrieving, and deleting source code and project files.
• User Service: Manages user-related operations such as registration, login, user profiles, and authentication/session information.
• Execution Service: Creates and manages code execution jobs. It validates execution requests and sends jobs to the message queue for asynchronous processing.
• Result Service: Retrieves and manages execution results and returns the output, errors, and execution status to the client.
• Message Queue: Stores code execution jobs and decouples the execution service from execution workers. Kafka or RabbitMQ can be used to support asynchronous and scalable job processing.
• Worker/Execution Servers: Consume execution jobs from the message queue and execute user programs. Multiple workers can process jobs concurrently to handle high execution volume.
• Code Storage: Stores source code and project files that need to be accessed during editing and execution.
• Container Registry: Stores container images containing the required language runtimes and execution environments, such as C++, Java, Python, and Node.js environments.
• Execution Result Storage: Stores execution outputs, errors, logs, and other generated execution artifacts that may need to be retrieved later.
• Redis Cache: Stores frequently accessed or temporary data such as session information, project metadata, execution status, and other cached data to reduce database load and improve response time.
• Database: Stores persistent application data such as users, projects, source-code metadata, execution jobs, execution history, and related information.
• Notification Service: Sends notifications to users about execution completion, errors, or other relevant events.
• Monitoring & Logging: Collects application and execution metrics, logs, worker health information, queue size, latency, resource usage, and security-related events for monitoring and troubleshooting.

Request Flow

The following flow describes how a user submits code for execution.

• The user writes code in the browser or mobile application and clicks Run.
• The request reaches the API Gateway, which authenticates the user and forwards the request to the Code Execution Service.
• The Code Execution Service validates the programming language, source code, and input, creates an execution job, and publishes it to the Execution Queue.
• An available Execution Worker consumes the execution job from the queue.
• The Execution Worker creates or assigns an isolated Execution Sandbox, then compiles and runs the code using the appropriate language runtime while enforcing CPU, memory, disk, network, and execution-time limits.
• After execution completes, the Execution Sandbox returns the program output, compilation errors, or runtime errors to the Result Service.
• The Result Service stores the execution result in Result Storage and updates the job status.
• The Result Service sends the execution result back to the Client through a REST API, WebSocket, or Server-Sent Events (SSE).
• The client displays the program output, compilation error, or runtime error to the user.

Data Flow

The data flow shows how source code, execution jobs, and results move through the system.

• The client sends source code and execution parameters to the API Gateway.
• The API Gateway authenticates the request and forwards it to the appropriate backend service.
• The Code Execution Service creates an execution job.
• The job is placed into Kafka or RabbitMQ for asynchronous processing.
• An Execution Worker consumes the job and starts an isolated sandbox.
• The sandbox loads the required compiler or runtime.
• The program is compiled and executed with the provided input.
• Execution output, errors, execution time, and status are collected.
• The result is stored in the database or appropriate storage system.
• The updated execution status is sent to the client in real time.
• Saved source files and large project artifacts can be stored in Object Storage.

5. Technology Stack

Before designing the data model, it is helpful to identify which technologies can be used by different components of the Online Code Editor.

6. Data Model Design

The data model defines how the Online Code Editor stores and manages users, projects, source files, execution jobs, and execution results. A good schema helps keep code organized and makes execution history easy to track.

• Identify the core entities required for code editing, storage, and execution.
• Define relationships between users, projects, files, and execution jobs.
• Select the appropriate database model based on consistency, scalability, and performance requirements.

Core Entities

The Online Code Editor system consists of the following core entities:

• User: Stores user profile, account, and authentication information.
• Project: Represents a coding project created by a user.
• CodeFile: Stores source code, file name, language, and project information.
• ExecutionJob: Stores code execution request, language, input, and job status.
• ExecutionResult: Stores output, errors, execution time, and execution status.
• LanguageRuntime: Stores information about supported compilers and runtime environments.

Database Selection

A combination of SQL, cache, and Object Storage can be used depending on system requirements.

• SQL Database is suitable for users, projects, execution jobs, and execution history because these require structured and consistent data.
• Redis can store temporary execution status, sessions, and frequently accessed project metadata.
• Object Storage can store source files, large projects, compiled artifacts, and other execution-related files.
• NoSQL Database can optionally be used for high-volume execution logs and analytics data.

7. API Design

The API design defines how users and client applications communicate with the Online Code Editor to manage projects, save code, execute programs, and retrieve execution results.

• Design REST APIs that are simple, scalable, and easy to use.
• Use appropriate HTTP methods for project, file, and execution operations.
• Secure APIs using authentication mechanisms such as JWT or OAuth 2.0.

Authentication APIs

Project APIs

Code File APIs

Execution APIs

Sample Request

POST/api/v1/executions

{
  "language": "python",
  "sourceCode": "print('Hello World')",
  "input": ""
}

Sample Response

{
"jobId": "job_501",
"status": "QUEUED",
"language": "python"
}

After execution completes:

{
"jobId": "job_501",
"status": "COMPLETED",
"output": "Hello World",
"executionTime": 0.12
}

8. Low Level Design

The Low-Level Design (LLD) describes the internal structure of the Online Code Editor by defining the main classes, their responsibilities, and their interactions.

Core Classes

The Online Code Editor can be designed using the following core classes:

• User: Manages user profile, account information, and projects.
• Project: Represents a coding project containing multiple source files.
• CodeFile: Stores file name, source code, programming language, and file metadata.
• ExecutionJob: Represents a code execution request and maintains its execution status.
• ExecutionResult: Stores output, errors, execution time, and memory usage.
• LanguageRuntime: Represents the compiler or runtime required to execute a particular language.
• ExecutionService: Handles job creation, sandbox allocation, code execution, and result collection.

SOLID Principles

The Online Code Editor follows SOLID principles to keep the system modular, maintainable, and easy to extend.

• Single Responsibility Principle (SRP): Each class handles one responsibility. For example, CodeFile manages source code while ExecutionService handles execution.
• Open/Closed Principle (OCP): New programming languages or execution environments can be added without modifying existing execution logic.
• Liskov Substitution Principle (LSP): Different language runtimes can be used through a common runtime interface.
• Interface Segregation Principle (ISP): Classes depend only on the methods required for their functionality.
• Dependency Inversion Principle (DIP): High-level execution services depend on abstractions rather than specific compilers, containers, or storage systems.

Design Patterns

9. Scalability & Performance

Scalability and performance ensure that the Online Code Editor can handle a large number of users and concurrent code executions while keeping execution fast, secure, and reliable.

• Load Balancing: A Load Balancer distributes API and execution requests across multiple backend servers.
• Horizontal Scaling: Additional Execution Service and worker instances can be added when code execution traffic increases.
• Execution Queue: Kafka or RabbitMQ buffers execution jobs so sudden traffic spikes do not overload workers.
• Sandbox Pooling: Pre-warmed containers or sandboxes reduce the time required to start code execution.
• Caching: Redis stores sessions, job status, and frequently accessed project metadata for faster access.
• Database Replication: Read replicas improve performance for project and execution-history queries.
• Asynchronous Processing: Code execution, logging, analytics, and result processing are handled asynchronously.
• Resource Limits: CPU, memory, execution time, and disk limits prevent a single program from consuming excessive resources.
• Auto Scaling: Execution workers can automatically scale based on queue size and CPU usage.
• Language-Based Worker Pools: Separate worker pools for languages such as C++, Java, and Python improve resource management.
• Multi-Region Deployment: Services can be deployed across multiple regions to improve availability and reduce latency.

10. Bottlenecks & Improvements

This section discusses the common challenges an Online Code Editor may face at scale and the techniques used to keep code execution secure, fast, and reliable.

Common Bottlenecks

• Execution Queue Backlog: A sudden spike in code submissions can create long waiting times for users.
• Sandbox Startup Delay: Creating a new container for every execution can increase response time.
• Resource Exhaustion: Infinite loops or memory-heavy programs may consume too much CPU or RAM.
• Language Runtime Overhead: Different compilers and runtimes can have different startup and execution costs.
• Database Bottleneck: Large numbers of projects, files, and execution-history requests can overload a single database.
• Worker Failure: An execution worker may crash while running user code.
• Security Risk: Malicious code may try to access the host system, network, or other users' data.

Possible Improvements

• Pre-Warmed Sandboxes: Keep ready-to-use containers available to reduce execution startup time.
• Auto Scaling: Add more execution workers based on queue length, CPU usage, and concurrent jobs.
• Strict Resource Limits: Apply CPU, memory, disk, network, and execution-time limits to every sandbox.
• Language-Based Worker Pools: Maintain separate optimized worker pools for different programming languages.
• Retry Mechanism: Retry failed execution jobs safely when failures are caused by infrastructure issues.
• Database Sharding & Replication: Distribute project and execution data across multiple databases for better scalability.
• Queue Prioritization: Prioritize interactive code runs over lower-priority background jobs.
• Monitoring & Alerting: Monitor queue length, execution latency, sandbox failures, resource usage, and security events.