Why I built a real simulator instead of another system design quiz

Most system design "practice" grades you on whether you drew the right boxes—cache here, load balancer there—checked against a keyword list. That never sat right with me, because the actual skill being tested in a system design interview isn't "do you know the vocabulary?" it's "Can you reason about what happens to this system under load."

So SystemInPain doesn't grade the diagram. It runs it. There's a deterministic simulation engine underneath—the same architecture and the same seed always produce the exact same result—and it pushes real seeded traffic through whatever you build, then measures p99 latency, availability, cost, and throughput under both steady load and injected failure scenarios (traffic spikes, node outages, and bot floods).

That's what catches the mistakes a checklist can't:

- Wiring an API straight to two DB replicas doubles your load instead of halving it (fan-out vs. split — a very common trap)

- An async queue absorbs bursts but silently drops writes under sustained overload—"having a queue" isn't the same as "handling the load"

- Failover only helps if detection is fast enough—redundancy isn't free