Requirements → Scale → Bottleneck → Solution
The four-step loop that lets you reason about any system at any scale. This is the platform's thesis.
Every good system-design conversation follows the same shape. It's not a straight line, it's a spiral: you make a choice, the choice unlocks more scale, more scale creates a new bottleneck, the bottleneck needs a new component, the new component introduces a new trade-off — and the loop starts again at the next scale tier.
Why this loop matters
Most learners memorize a URL Shortener architecture and think they've learned system design. They haven't. At 10K RPS the "right" architecture is one Postgres and three app servers. At 100K RPS you add Redis. At 1M RPS you shard writes. At 1B you push the redirect to the edge. The problem didn't change — the scale did.
Once you internalize the loop, every problem becomes the same problem with different starting numbers. You don't need to memorize a Netflix architecture. You need to know how to spiral.
The four questions
What are the requirements?
Functional, non-functional, and out-of-scope. Do this before you draw anything. Ninety percent of interview failures start with skipping this step.
At this scale, what breaks?
Estimate the traffic, storage, and bandwidth first. Then ask: "What's the first thing to melt?" The answer is almost always the database.
What component fixes the bottleneck?
Cache. Read replicas. Sharding. Queue. CDN. Each has a known job. You're not inventing anything — you're choosing.
What new trade-off did I just accept?
Every fix is a trade. Cache = stale reads. Read replica = replication lag. Sharding = hot shards. Say the trade-off out loud, then move on.
Practice
The URL Shortener flagship problem shows the entire loop across four scale tiers. Watch how the same problem produces four different architectures — and notice how each new component introduces exactly one new trade-off.
Practice what you just read
Every foundation concept has a companion quiz to close the loop.