Design LeetCode

Problem Statement

Build an online platform where developers participate in timed programming contests by solving algorithmic challenges. Users submit code in multiple programming languages, which must be compiled, executed against hidden test cases, and scored in real time. The system displays live rankings that update as submissions are evaluated and supports both individual practice and competitive events with enforced time windows.

The design must safely execute untrusted code from thousands of concurrent participants without compromising infrastructure, deliver verdicts within seconds, and maintain leaderboard accuracy when many users solve problems simultaneously. Key challenges include sandboxing arbitrary code, scaling the evaluation pipeline under bursty contest traffic, preventing double-scoring on retries, and ensuring fairness through consistent test environments and anti-cheating measures.

Key Requirements

Functional

• Problem catalog -- users browse and filter problems by difficulty, tags, and contest; each problem includes description, constraints, examples, and acceptance rate
• Code submission -- users submit solutions in various languages (Python, Java, C++, Go) and receive compilation feedback and detailed test results with pass/fail status
• Timed contests -- contests have strict start and end times, allow multiple submission attempts per problem, apply time penalties for wrong answers, and freeze standings near the end
• Live leaderboard -- display top performers with scores and solve times, show the user's current rank, and provide a paginated "around me" view of nearby rankings

Non-Functional

• Scalability -- handle 50,000 concurrent contest participants with 5 to 10 submissions per minute per user during peak periods
• Reliability -- evaluate all submissions exactly once, maintain leaderboard consistency across failures, and preserve submission history for dispute resolution
• Latency -- return compilation errors within 2 seconds, complete test execution for standard problems within 5 seconds, and update leaderboards within 1 second of verdict
• Consistency -- guarantee eventual consistency for leaderboards with conflict resolution for simultaneous submissions; strong consistency for user scores within contests

What Interviewers Focus On

Based on real interview experiences, these are the areas interviewers probe most deeply:

1. Code Execution Safety and Isolation

Executing arbitrary user code is the highest security and reliability risk. Interviewers want to see how you prevent resource exhaustion, sandbox escapes, and cascading failures from malicious or buggy submissions.

Hints to consider:

• Use containerized sandboxes with strict CPU, memory, and time limits enforced at the kernel level (cgroups, seccomp)
• Execute code in isolated worker pools separate from API servers, with network access disabled inside containers
• Implement multiple layers of defense: language-specific restrictions, system call filtering, and disk quotas
• Consider lightweight VMs or gVisor for stronger isolation than standard containers when dealing with untrusted code

2. Asynchronous Submission Pipeline

Compilation and test execution are too slow for synchronous request-response. Interviewers expect a robust async pipeline that handles retries, failures, and backpressure without losing submissions or double-scoring.

Hints to consider:

• Use a message queue (Kafka, SQS) to decouple submission ingestion from evaluation, enabling horizontal scaling of workers
• Implement idempotent processing with submission IDs so that retries do not create duplicate scores
• Design clear state transitions (Pending, Compiling, Running, Completed, Failed) with timeouts at each stage
• Add dead-letter queues for submissions that fail repeatedly, with operator alerting and manual reprocessing

3. Real-Time Leaderboard Design

During active contests, leaderboards must reflect new scores within seconds while supporting thousands of concurrent readers. Recomputing rankings from the database on every request is too expensive.

Hints to consider:

• Materialize leaderboards in Redis sorted sets keyed by contest ID, with user IDs as members and composite scores (solved count, penalty time) as values
• Update scores atomically as verdicts complete using Redis ZADD operations
• Cache top-N slices and individual user ranks separately to serve common queries efficiently
• Handle tie-breaking rules consistently by encoding multiple scoring dimensions into the sorted set score

4. Contest Fairness and Integrity

Competitive integrity requires preventing late submissions, detecting plagiarism, and ensuring all users are judged by identical test cases. Interviewers look for how you enforce rules at scale.

Hints to consider:

• Validate contest eligibility and time windows at submission time using server-side clock checks, never trusting client timestamps
• Store test cases separately from problem statements and never expose them in API responses
• Implement submission fingerprinting or code similarity detection to flag potential plagiarism for review
• Design penalty systems that account for wrong submissions and time taken, using consistent formulas applied at score-update time

Suggested Approach

Step 1: Clarify Requirements

Confirm how many concurrent users the system must support during peak contests and whether practice mode has different scaling requirements. Clarify which programming languages are required and whether custom libraries need support. Establish expectations around verdict latency and whether partial credit exists for individual test cases. Ask about contest formats, team competitions, and anti-cheating priorities.

Step 2: High-Level Architecture

Sketch a system with three tiers. The API layer handles user requests, serves problem content from cache, accepts submissions, and queries leaderboard state. The evaluation layer consists of worker pools that pull submissions from a message queue, compile code in sandboxes, execute test cases with resource limits, and publish verdicts. The storage layer includes PostgreSQL for users, problems, submissions, and contest metadata; Redis for live leaderboards and problem content caching; and Kafka for submission events and verdict notifications. Connect these tiers with the message queue for submission flow and a pub-sub channel for pushing real-time verdict notifications to clients via SSE or WebSocket.

Step 3: Deep Dive on Submission Evaluation

Walk through a submission lifecycle. The user submits code and the API server validates contest eligibility, assigns a unique submission ID, persists the record with Pending status, and publishes a message to the evaluation queue partitioned by problem ID. A worker claims the message, pulls the code and test cases, spins up an isolated container with CPU and memory cgroups, compiles the code with a timeout, and runs it against each test case sequentially. Each test is time-boxed and monitored for illegal system calls. The worker aggregates results (Accepted, Wrong Answer, Time Limit Exceeded), updates the submission record, calculates the user's new score based on contest rules, and atomically updates the Redis leaderboard. Discuss how partitioning the queue by problem ID distributes load fairly and prevents one popular problem from starving workers processing others.

Step 4: Address Secondary Concerns

Cover how the leaderboard serves reads: top-N queries use Redis ZREVRANGE, and "around me" queries use ZRANK plus a range fetch. Discuss caching strategies for problem statements and how to invalidate them when admins update content. Explain the database schema: normalize users, contests, problems, and submissions with indexes on contest_id and user_id for efficient queries. Address monitoring by tracking submission rates, queue depths, worker utilization, and verdict latency. Mention rate limiting on submissions per user to prevent abuse. Touch on dispute resolution by storing complete test outputs for admin review.

Related Learning Resources

• Job Scheduler guide -- covers asynchronous task pipelines, worker pool management, and retry strategies
• Message Queues -- queue-based load leveling, partitioning, and backpressure handling
• Caching -- Redis sorted sets for leaderboards and cache invalidation patterns