You open the virtual whiteboard. The interviewer says: "Design a URL shortener — 10,000 requests a second, 99.9% availability, custom aliases, click analytics. Scope it for a minute, then walk me through it."
You've practised this one. You've read the blog posts, watched the YouTube walkthrough, maybe even memorised a diagram. You draw your boxes — load balancer, application server, database, cache. You explain Base62 encoding. You mention consistent hashing. And then the interviewer asks one question you didn't rehearse, and the whole thing unravels.
Every system design interview practice guide covers the URL shortener. It's the "Hello World" of the format. So why do candidates still fail it? Because the textbook answer is table stakes. Interviewers have heard it hundreds of times. They're not testing whether you can recall an architecture — they're testing whether you can think in one.
What Makes System Design Interviews So Difficult
A system design interview is a structured conversation where candidates propose and defend an architecture for a given problem, demonstrating their ability to reason about scalability, reliability, and tradeoffs under constraints. It's not a quiz. It's a simulation of the hardest part of an engineer's job: making decisions with incomplete information and defending them under scrutiny.
What makes this format brutal is that there's no single correct answer. A coding challenge has test cases. A behavioural question has the STAR framework. System design has... it depends. The interviewer is evaluating five things simultaneously:
- Did you scope requirements and estimate scale before touching a whiteboard?
- Did you define a clear data model and API surface?
- Did you make deliberate storage and caching choices — and justify them?
- Did you address the hard parts — hot keys, read/write split, availability guarantees?
- Could you defend your choices when a scaling assumption was challenged?
Most candidates fail on points 1 and 5. They jump straight into drawing boxes (skipping the scoping that separates senior engineers from juniors) and then freeze when the interviewer pushes back on a design decision.
Here's what that looks like in practice. A candidate proposes a single relational database for the URL mappings. Fine for the initial design. The interviewer asks: "What happens when traffic grows 50x in a year?" The candidate says "we can shard it" but can't explain the sharding strategy, the rebalancing plan, or what happens to custom aliases that now span multiple shards. The answer collapses because it was memorised, not understood.
According to interviewing.io's analysis of thousands of technical interviews, system design has the lowest pass rate of any interview type — roughly 45% compared to 55% for algorithms. The gap widens at senior levels, where interviewers probe deeper into tradeoffs and operational concerns.
How to Actually Pass a System Design Interview
Stop memorising architectures. Start building a repeatable thinking process. Here's the framework I'd use for any system design question, including the URL shortener:
1. Scope before you sketch (2-3 minutes). Ask clarifying questions. For a URL shortener: What's the read-to-write ratio? Do we need analytics? What's the expected URL lifetime? A 1000:1 read-to-write ratio fundamentally changes your caching strategy. Candidates who skip this step design for assumptions they never validated.
2. Estimate the numbers. 10,000 requests per second. If 95% are reads, that's 9,500 reads/sec and 500 writes/sec. At 500 writes/sec, you're storing roughly 43 million new URLs per day. Over five years, that's ~80 billion records. These numbers tell you whether a single Postgres instance is viable (it isn't) and whether you need a distributed cache (you do).
3. Define the API and data model first. Before drawing infrastructure boxes, specify the endpoints: POST /urls to create, GET /:shortCode to redirect, GET /:shortCode/stats for analytics. Define the schema: short_code (primary key), original_url, created_at, expiry, click_count. This grounds the entire conversation.
4. Make storage decisions explicit. A good answer: "I'm choosing DynamoDB for URL mappings because the access pattern is simple key-value lookups at high throughput, and I need horizontal scalability. I'm adding Redis as a read-through cache because 95% of requests are reads and popular URLs will have extreme hot-key behaviour." A bad answer: "We'll use a database and add caching." The first shows engineering judgment. The second shows vocabulary.
5. Address failure modes unprompted. What happens when a cache node dies? What's your fallback for the 0.1% downtime budget in 99.9% availability — that's 8.7 hours per year? How do you handle a viral URL that suddenly gets 100x its normal traffic? Raising these yourself signals seniority. Waiting to be asked signals you haven't operated real systems.
6. Defend with tradeoffs, not absolutes. When the interviewer challenges you ("Why not Cassandra instead of DynamoDB?"), don't panic. Respond with tradeoffs: "Cassandra gives me tunable consistency and avoids vendor lock-in, but DynamoDB's managed infrastructure reduces operational overhead for a small team. I'd choose Cassandra if we had a dedicated infrastructure team." This is what interviewers want. Not the "right" answer — a reasoned one.
The difference between a pass and a fail is rarely knowledge. Google's internal hiring data shows that interviewers reach consensus on system design candidates only 60% of the time — lower than any other interview type. The signal is noisy because what's being measured isn't facts. It's judgment.
Practice Changes Everything
Reading a system design guide is like reading a book about swimming. You understand the theory. You can describe the strokes. But the moment you hit water, nothing works the way you expected.
The real challenge of system design interviews isn't knowing what a load balancer does — it's maintaining composure when the interviewer throws a curveball like: "One region must serve all writes for compliance while reads must be globally low-latency." That constraint invalidates half your architecture. Can you adapt in real time, or do you stare at the whiteboard?
This is exactly why we built system design practice into MORT's interview simulator. Static diagrams don't prepare you for an interviewer who pushes back, introduces complications, or asks you to re-scope mid-conversation. From building MORT, I've seen that candidates who practise with dynamic follow-ups — where the system challenges their assumptions rather than accepting them — improve their system design pass rates measurably faster than those who only study written guides. The gap isn't knowledge. It's the ability to think on your feet while someone pokes holes in your reasoning.
If you're preparing for incident response scenarios or metric investigation questions, the same principle applies: the scenarios that feel uncomfortable in practice are the ones you'll handle with confidence in the real interview.
The Real Test
Here's the one thing to take away: your URL shortener answer needs to be yours, not the internet's. Use the same building blocks everyone else uses — but know why you chose each one, and be ready to swap any of them when the constraints change.
The best system design candidates I've observed through MORT don't have better technical knowledge than the ones who fail. They have better questions. They ask "what problem am I actually solving?" before they ask "what technology should I use?" That instinct isn't something you can memorise. It's something you build through reps.