Design Leetcode

Non-Functional Requirements (How well the system should perform)

1. Scale: Support 50,000 concurrent users
2. Latency: Leaderboard updates within 10 seconds
3. Security: Safely execute potentially malicious user code
4. Performance: Fast code execution and submission processing

💡 Pro Tip: Always start with requirements! They guide every decision you'll make in your design.

Step 2: API Design

The API defines how clients communicate with our system. Think of it as the "menu" of actions users can perform.

Core Endpoints

Why These Endpoints?

• GET requests for reading data (problems, leaderboards)
• POST requests for creating/updating data (code submissions)
• Pagination prevents overwhelming responses
• URL parameters for required identifiers (problemId, contestId)
• Query parameters for optional filters (offset, limit)

Step 3: Database Design

Our system needs to store several types of data. Let's identify the main entities:

Core Entities

1. Users: Store user information and authentication data
2. Problems: Coding challenges with descriptions, constraints, examples
3. Submissions: User code submissions with results and timestamps
4. Contests: Competition details, participating problems, and duration
5. Leaderboards: Contest rankings and scores

Key Relationships

• Users can have multiple submissions (one-to-many)
• Each submission belongs to one problem (many-to-one)
• Contests can include multiple problems (many-to-many)
• Users can participate in multiple contests (many-to-many)

🎯 Quick Note: We don't need to design every table field right now. Focus on understanding the relationships between entities.

Step 4: High-Level System Architecture

Now comes the exciting part – designing the actual system! Let's start simple and add complexity as needed.

Basic Architecture

This handles basic operations like viewing problems. The web server processes requests and fetches data from the database.

Adding Code Execution

We can't just run user code directly on our web servers – that would be a massive security risk! Imagine if someone submitted code that tried to:

• Access our database
• Mine cryptocurrency on our servers
• Delete important files
• Make unauthorized network requests

The Solution: Isolated Code Execution

How it works:

1. User submits code to the web server
2. Web server stores submission in the database
3. Code execution request goes to a message queue
4. Specialized workers pick up jobs from the queue
5. Workers execute code in isolated environments
6. Results are stored back in the database

Why Use a Message Queue?

A message queue acts like a buffer between your web server and code execution workers. Benefits include:

• Reliability: If a worker crashes, the job stays in the queue
• Scalability: Add more workers during high traffic
• Decoupling: Web server doesn't wait for slow code execution

Popular message queues: Apache Kafka, RabbitMQ, Amazon SQS

Step 5: Secure Code Execution Deep Dive

This is one of the most critical parts of our system. Let's explore different approaches to safely execute untrusted code.

Option 1: Virtual Machines (VMs)

• Pros: Maximum isolation, very secure
• Cons: Slow to start, expensive

Option 2: Docker Containers (Recommended)

• Pros: Fast startup, good isolation, resource limits
• Cons: Slightly less secure than VMs (but sufficient)

Option 3: Cloud Functions

• Pros: Auto-scaling, managed infrastructure
• Cons: Vendor lock-in, latency issues

Option 4: WebAssembly (Creative)

• Pros: Runs in user's browser, no server costs
• Cons: Limited language support

Our Choice: Docker Containers

Docker gives us the best mix of isolation, speed, and cost.

Container Configuration:

• No network access
• Limited file system
• Memory limit (e.g., 128MB)
• CPU and timeout limits

Execution Flow

1. Receive code submission
2. Create a secure Docker container
3. Execute code against test cases
4. Compare output with expected results
5. Return pass/fail
6. Destroy container

Step 6: Real-Time Leaderboards

How do we handle thousands of users watching leaderboards?

Naive Approach (Don’t do this!)

Problems:

• Slow, especially with lots of data
• Poor performance under load

Smart Approach: Redis Sorted Sets

Redis offers in-memory Sorted Sets that auto-maintain order.

Benefits:

• O(log n) insert
• O(n) retrieval
• High-speed leaderboard updates

Leaderboard Example

Updating in Real Time

Client-side polling every 10 seconds works well:

• 50,000 users → 5,000 requests/second
• Redis handles this easily

Bonus: Use WebSockets for true real-time but requires more infra

Step 7: Advanced Considerations

Handling Traffic Spikes

• Auto-scale execution workers
• Pre-scale before contests
• Rate limit abusive users
• Load balance across servers

Ensuring Data Consistency

If Redis update fails but DB write succeeds:

• Use Change Data Capture (CDC) tools like Debezium
• Sync DB → Redis via message queue

Test Case Management

Run user code against multiple test cases:

Approach:

• Store test cases in files
• Use driver code to run user solution
• Compare actual vs. expected output
• Language-agnostic format

Example Test Case File:

Step 8: Complete System Architecture

Performance Characteristics

Scalability

• 50,000 concurrent users
• Message queue smooths spikes
• Redis supports 5,000+ reads/sec

Latency

• Code execution: 1–10 seconds
• Leaderboard updates: < 10 seconds
• Problem viewing: sub-second

Security

• Containerized execution
• CPU/memory/time/network sandboxing

Key Takeaways for Beginners

1. Start with requirements – don’t rush into coding
2. Sandbox user code – never trust it
3. Choose efficient structures – like Redis Sorted Sets
4. Design for scale – use queues and caches early
5. Understand trade-offs – speed vs. safety, cost vs. performance
6. Test and monitor – always plan for real-world failure

What's Next?

• Practice by designing systems like HackerRank or Twitter
• Build a basic version of this project
• Study distributed systems, Redis, Docker, Kafka
• Experiment with WebSockets, CDC tools

Conclusion

We’ve gone from basic requirements to a scalable, secure architecture ready for production. The key principles:

• Security first
• Scale thoughtfully
• Start simple
• Plan for failure

System design can feel overwhelming, but step-by-step planning makes it approachable.

Happy designing! 🚀

Want to practice system design? Try designing other popular systems like Twitter, Netflix, or Uber.

The principles you learned here apply everywhere!