Design LeetCode

Each phase is what the interviewer expects you to do and say. Concrete steps, not topic hints. The diagrams are what you sketch on the board.

1. 1

   Clarify Requirements and Scale

   5 min

   GoalForce the security question first. Running untrusted code is the whole ballgame, and most candidates skip past it to the queue.

   Do & Say

   1. SAY·1SAY: “the hard part is not the queue, it's running untrusted code safely”. Confirm: “arbitrary code from millions of strangers” including “fork bombs”, “kernel exploits”, “infinite loops”. Get a yes.
   2. SAY·2Pin scale: “50M submissions/day”, “580/sec average”, “2K/sec peak”, “20K concurrent during contest windows”, “20+ programming languages”. Write on the board.
   3. SAY·3Pin SLAs: “p95 submission-to-verdict < 5s”, “p99 < 10s”, “99.99% availability during contests”, “zero sandbox escapes (hard requirement)”. Wait for nod.
   4. SAY·4State scope. In scope: “secure execution”, “multi-language compile + run”, “real-time contest leaderboard”, “post-contest Elo rating”, “premium priority queue”. Out of scope: “problem editing UI”, “payment for premium”, “discussion forums”, “editorial solutions”.
   5. SAY·5Drop the bait: “I'm going to argue for Firecracker microVMs over gVisor and Docker-with-seccomp”. The choice drives the entire pool architecture. OK to defend that now? Get them to confirm now.

   Interviewer is grading: You name the sandbox-escape rate as a hard requirement, not a soft SLA. You force the isolation-tech question early because it drives everything else.

2. 2

   Sandbox Isolation Comparison

   7 min

   GoalThree isolation candidates, knock out two, defend Firecracker with the AWS Lambda precedent and the boot-time math.

   Do & Say

   1. SAY·1Write three candidates: “Docker + seccomp”, “gVisor”, “Firecracker microVMs”. All three exist in production. The decision is driven by “syscall compatibility”, “cold-start latency”, “sandbox-escape blast radius”.
   2. WATCH·2Kill Docker + seccomp: “shared kernel”, “CVE-2019-5736 (runc)”, “CVE-2020-15257 (containerd)”, “6+ known escape CVEs in last 5 years”. Even with a 50-syscall seccomp allowlist, every kernel zero-day is a host compromise. For 50M arbitrary programs/day, the math doesn't work. Cross it off.
   3. SAY·3gVisor next: “Google's user-space kernel”, “Sentry (Go) intercepts and reimplements every syscall”, “high security but only 95% syscall compatibility”, “I/O-heavy code sees 10-30% overhead”. Viable but not optimal.
   4. SAY·4Land on Firecracker: “100% syscall compat (guest runs a real Linux kernel)”, “hardware KVM boundary, not software Sentry”, “zero known escape CVEs”, “~5MB VMM, ~35MB per microVM”. AWS Lambda runs billions on it, not theoretical.
   5. SAY·5Boot-time math: “cold boot ~125ms (start VMM, load ~4MB kernel, mount rootfs, init runtime)” too slow at 2K/sec. “Firecracker native snapshot/restore (no CRIU) restores a fully-initialized VM in ~25ms” (Python stdlib imported, JVM JIT-warm). 5x faster, makes the warm pool feasible.
   6. WATCH·6Get ahead of “why not Kata?”: “Kata Containers wraps Firecracker behind the OCI runtime interface”, “K8s sees it as a normal pod”, “HPA + KEDA + rolling deployments work unchanged”. Without Kata, we'd need a custom orchestrator.

   Interviewer is grading: Three options compared with one-line kills (CVE count for Docker, 95% compatibility for gVisor). You quote AWS Lambda as precedent. You explain why Kata Containers bridges Firecracker into Kubernetes instead of building a custom orchestrator.

3. 3

   High-Level Design

   10 min

   GoalDraw three independent paths. Submission async via Kafka. Execution on warm pool. Contest leaderboard with atomic Lua + WebSocket.

   Draw on the board
   Do & Say

   1. SAY·1Walk submit: “API validates code length + language”, “Valkey rate limit (5/min practice, 10/min contest)”, “write submission row to Postgres as PENDING”, “produce to one of four Kafka topics by priority”, “return 202 with submission_id”. HTTP request completes in under 100ms.
   2. SAY·2Why four topics: “single topic can't prioritize within a partition”. Four topics with dedicated worker pools: “contest (CRITICAL)”, “premium (HIGH)”, “practice (NORMAL)”, “custom-test (LOW)”. Practice workers dual-consume contest on spike via adaptive consumer with hysteresis, so contest never sits in lag.
   3. SAY·3Walk execution: “worker pulls Kafka”, “claims a warm microVM”, “95%+ hit a ready VM in ~2ms”, “burst falls back to ~25ms snapshot restore”. VM flow: “write code via vsock”, “compile”, “run test cases via stdin/stdout”, “capture wall-time + peak memory from cgroup”, “stop on first failure unless Accepted”.
   4. SAY·4Drop the killer line on VM reset: “after each submission, restore the VM from a pre-execution diff snapshot”, “reverts all filesystem + memory changes in ~5ms”, “one VM serves multiple submissions back-to-back without being destroyed”. Saves the full ~25ms snapshot restore.
   5. SAY·5Walk contest path on Accepted: “Valkey Lua script atomically checks duplicate via HGET problem_accepted”, “marks accepted”, “increments problems_solved”, “computes penalty = solve_time + wrong_attempts*5min”, “ZADD score = problems_solved*1e9 - total_penalty”, “PUBLISH contest:id:update”. WebSocket gateways push live deltas.
   6. SAY·6Why score = solved × 10^9 minus penalty: “sort by problems_solved descending”, “tiebreak by penalty ascending”, “one numeric score lets Valkey ZSET do the sort for free”. Wrong_attempts only increment if the problem isn't already accepted, in a separate Lua script.
   7. SAY·7Storage math: “PostgreSQL ~1.5TB hot (30 days, weekly partitions)”, “S3 ~36.5TB/year source code, lifecycle to S3-IA after 90 days”, “Valkey ~150MB total (leaderboards, rate limits, sessions), one node”, “1,500 worker pods × 8 VM slots = 12K concurrent VMs”, “14.5% steady-state util”.

   Interviewer is grading: Four Kafka topics with dedicated pools, not one with priority field. Diff snapshot VM reset at ~5ms is named explicitly. Lua script atomicity is justified, not assumed. The score = solved × 10^9 minus penalty encoding is volunteered, not asked for.

4. 4

   Deep Dive: Warm Pool, Contest Spikes, and Elo

   13 min

   GoalThree sub-dives with concrete algorithms and numbers.

   Draw on the board
   Do & Say

   1. SAY·1Warm pool sub-dive: “pool maintains N pre-restored microVMs per language”. Default sizes: “python3=200”, “java=150”, “cpp=150”, “go=100”. Pool adjusts every 5 seconds: “target_idle = max(min_idle_floor, demand_5min_avg × 1.5, contest_pre_warm)”. Walk the diagram.
   2. SAY·2Contest pre-warming: “15 minutes before a weekly contest, pool boosts by historical language distribution”: “Python 45%”, “C++ 30%”, “Java 15%”, “others 10%”. Dynamic rebalancing steals idle VMs from low-demand languages.
   3. SAY·3VM health scoring: each VM tracks “age (max 60 min)” and “execution count (max 100)”. “Health below 0.3 → kill and replace from snapshot”, “no VM lives past an hour”. This is a security rotation, not a perf tweak. Limits blast radius of any future Firecracker CVE.
   4. SAY·4Spike handling sub-dive: “contest start moves traffic from 580/sec to ~3,000/sec”. “KEDA auto-scales worker pods on Kafka consumer lag, not on CPU”. CPU lags Kafka lag by minutes because pods spin up, restore VMs, then start consuming. Lag is the right signal.
   5. SAY·5Practice workers dual-consume: “non-blocking poll on contest topic first, then blocking poll on practice”, “steal contest work when contest lag > threshold”, “stop when lag < threshold/3”. Hysteresis prevents flapping. Contest submissions are never delayed by practice traffic.
   6. WATCH·6Be ready for the fairness question: “during contests, premium subscribers do NOT jump the line”, “all contest submissions are equal priority regardless of premium tier”, “fairness is non-negotiable”. Premium priority only applies to practice submissions, not contests.
   7. SAY·7Elo sub-dive: “live leaderboard uses penalty-time during the contest”, “Elo runs after, async”. For N participants, treat as round-robin: “Expected Rank = sum of 1/(1+10^((opp-player)/400)) over all opponents”, “Delta = K*(ln(expected) - ln(actual))”, “clamped to [-150, +150]”.
   8. SAY·8Elo K-factor: “K = max(20, 80 - contests_played × 2)”. “Starts at 80 for new players”, “decays to 20 with experience”, “starting rating 1500”. High volatility early, stable late. Same approach LeetCode introduced in 2020.
   9. WATCH·9Be ready for cheating: “same code, two machines, 48ms vs 72ms from noisy neighbors”, “raw exec-time ranking is unfair”. We normalize by language multiplier (“C++ 1.0x”, “Java 2.0x”, “Python 3.0x”) but rank by “problems_solved then penalty”, never raw time. Exec time is shown to the user, not used for ranking.

   Interviewer is grading: You name health scoring with the 60-min age cap and explain it as a security rotation, not a perf tweak. You volunteer that premium does NOT cut contest lines. You quote LeetCode's 2020 Elo introduction and walk the multi-player adaptation.

5. 5

   Trade-offs and Wrap-up

   5 min

   GoalThree deliberate trade-offs, one operational tail risk, one-sentence summary.

   Do & Say

   1. SAY·1Bare-metal trade-off: “Firecracker needs /dev/kvm”, “bare-metal K8s nodes (c5.metal, m5.metal) or nested-virt instances”, “2-3x EC2 cost”. We pay for the hardware-enforced boundary. gVisor on regular nodes is cheaper, but 10-30% I/O overhead and 95% syscall compat kill it for a multi-language platform.
   2. SAY·2Time-limit multiplier trade-off: “same algo in C++ runs 5ms, Python takes 50ms”. We multiply base time by language (“C++ 1.0x”, “Java 2.0x”, “Python 3.0x”) so Python gets 3x. LeetCode skips this and Python users complain. We accept setter complexity because per-language fairness matters on a learning platform.
   3. SAY·3Test case storage trade-off: “test cases live in S3”, “cached on worker SSDs”, “never in the rootfs image”. Inside the image, users could read expected outputs and hardcode. “SSD hit sub-ms”, “cold S3 fetch 50-100ms”, “total under 2GB fits on worker SSDs”.
   4. SAY·4Operational risk: “Kafka outage during contest is tier-1: no ingest, no verdicts, no leaderboard”. Mitigations: “RF=3 across 3 brokers”, “MirrorMaker to standby”, “idempotent producer”. “5-min outage buffers in API memory with 30s timeout then client retries”. We don't extend contests but credit penalty time.
   5. SAY·5Close: “Firecracker microVMs with hardware KVM (100% syscall compat + zero-CVE radius at 50M/day)”, “warm pool with ~25ms snapshot restore makes boot math work”, “four Kafka topics with priority pools for contest fairness”, “Valkey Lua + PUBLISH + WebSocket for sub-second leaderboard”, “Elo runs async post-contest”.
   6. SAY·6Offer deeper dives: “Firecracker snapshot API details”, “dual-consume hysteresis math”, “Elo multi-player adaptation”, or “per-language rootfs build pipeline”.

   Interviewer is grading: Bare-metal cost trade-off is acknowledged with a number (2-3x). Test cases are kept out of the image with the security reason given (hardcoded answers). The closing summary names Firecracker as load-bearing and explains why no alternative meets all three constraints.

Questions an interviewer is likely to ask after your walkthrough. Rehearse the short answer.

1. Why Firecracker and not gVisor?
2. How does the warm pool keep claim time under 5ms?
3. Why score = solved × 10^9 minus penalty instead of separate fields?
4. What stops premium subscribers from gaming contests?
5. How does multi-player Elo work after a contest?
6. What's the failure mode for the Kafka broker during a contest?
7. Why kill VMs at 60 minutes even if they're healthy?
8. How are test cases protected from being read by user code?