LeetDesign

System design practice, with teeth

Draw your design. Run it under load. See how it holds up.

LeetDesign grades system design submissions the way a real interviewer would — against named invariants and quantitative load, not a hidden answer key. Many topologies pass. Broken ones fail with a specific reason.

How the grader works

01

Invariant checks

Each problem ships with explicit graph invariants — caching layers, replication factors, single points of failure. Your design passes or it doesn't, with the failing node named.

02

Traffic simulation

Stated load profiles run through your diagram. You see hot spots, queue depth, and p99 latency per flow. Either your design handles the load or it visibly doesn't.

03

Named bottlenecks

Verdicts point at nodes, not vibes. A failing design tells you which component saturated, at what utilization, under which workload — so the fix is obvious.

What's live today

We're rebuilding LeetDesign from scratch in public, one problem at a time. The Key-Value Store brief and the diagram editor are live today; the deterministic grader is being rebuilt against them now.

Problem brief · interview-complete Key-Value Store — live

Diagram editor · typed components, ports, export — live

Deterministic grader · invariants + load simulation — in progress