How to Approach System Design Interviews (Without Panicking)

System design interviews feel different from LeetCode rounds. Nobody hands you a function signature and waits for O(n log n). Instead, you get a vague prompt — "design Twitter" or "design a parking lot" — and forty-five minutes to show you can think like an engineer who ships real software. The good news: interviewers are not looking for a perfect architecture. They want to see structured thinking, reasonable trade-offs, and honest communication when you do not know something.

I have sat on both sides of these conversations. Candidates who pass are rarely the ones who memorise every AWS service. They are the ones who slow down, ask questions, and build the design in layers instead of dumping buzzwords.

What interviewers actually evaluate

Before we talk about boxes and arrows, understand the rubric. Most companies score roughly four areas:

• Requirement gathering — Do you clarify functional and non-functional needs before designing?
• High-level design — Can you decompose the problem into services or components that make sense?
• Deep dives — When the interviewer zooms in on one piece (the feed, the database, caching), can you go one level deeper with specifics?
• Trade-offs — Do you explain why you chose SQL over NoSQL, or synchronous calls over async queues, instead of treating every decision as obvious?

The 45-minute framework I recommend

Use this as a pacing guide. Adjust if your interviewer wants to skip ahead or dive straight into storage.

1. Minutes 0–5: Clarify requirements and constraints
2. Minutes 5–10: Back-of-envelope capacity estimation
3. Minutes 10–20: High-level architecture (API + main components)
4. Minutes 20–35: Deep dive on 1–2 critical paths
5. Minutes 35–45: Bottlenecks, failure modes, and what you would do next with more time

Step 1: Clarify requirements (do not skip this)

The prompt is intentionally incomplete. "Design a URL shortener" could mean a hobby project or bit.ly at global scale. Your first job is to narrow the scope with the interviewer.

Functional requirements

Ask what the system must do. For a URL shortener, that might be: shorten a long URL, redirect when someone visits the short link, optional custom aliases, optional expiration. Write these down visibly — whiteboard, Excalidraw, or shared doc.

Non-functional requirements

This is where senior candidates separate themselves. Ask about read/write ratio, latency expectations, availability targets, consistency needs, and geographic distribution. A redirect service is read-heavy. A payment ledger is write-heavy and needs strong consistency.

• How many users? Daily active users (DAU) matters more than registered accounts.
• How many operations per second (QPS) for reads and writes?
• What latency is acceptable? Sub-100ms for redirects vs. seconds for batch reports.
• Can we lose data? Eventual consistency is often fine for social feeds; not for bank balances.
• Do we need authentication, analytics, admin dashboards? Often out of scope unless stated.

Step 2: Rough capacity estimation

You are not trying to be precise. You are showing you can connect product numbers to engineering decisions. Interviewers love seeing napkin math.

Example: 50 million new short links per month, 100:1 read-to-write ratio. That is roughly 20 writes/sec average (50M / 30 days / 86400), peaking maybe 5× at 100 writes/sec. Reads: 2,000/sec average, 10,000/sec peak. Storage: if each mapping is ~500 bytes, 50M/month × 12 months × 500 bytes ≈ 300 GB/year before replication. Suddenly you know a single beefy database might work initially, but you need caching for reads.

Step 3: High-level design

Start simple. A load balancer, an application tier, a database, and maybe a cache is a fine opening sketch for many problems. Name your APIs early — it forces you to think about data flow.

Define the API contract

For the URL shortener: POST /api/urls with { longUrl, customAlias?, ttl? } returns { shortUrl }. GET /{shortCode} returns HTTP 302 to the long URL. That is enough to drive your data model: you need to store shortCode → longUrl, plus metadata like createdAt and expiry.

Pick a data model before optimising

A relational table works: id, short_code (unique index), long_url, created_at, expires_at. The redirect path is a single indexed lookup. You can shard later by short_code hash if needed. Resist jumping to Cassandra because you heard Netflix uses it.

Step 4: Deep dives the interviewer will probe

They will pick the interesting part. For read-heavy systems, that is usually caching and CDN. For write-heavy systems, it is partitioning and write amplification. For social products, it is fan-out on write vs fan-out on read.

• How do you generate short codes? Base62 encoding of an auto-increment ID, or hash with collision handling?
• What happens when the database is down? Read-through cache might still serve hot links; new writes fail gracefully.
• How do you prevent abuse? Rate limiting per IP, CAPTCHA on create, blocklist for malicious domains.

Step 5: Discuss trade-offs out loud

Every design choice has a cost. Say it. "I am using PostgreSQL because we need strong uniqueness on short codes and our write volume is modest. If writes grew 100×, I would consider separating the ID generation service and using a write-optimised store." That sentence alone signals maturity.

What to do when you are stuck

Silence is worse than uncertainty. Say: "I have not built a global chat system before, but I would start by separating the message store from the presence service. Let me think through how delivery guarantees would work." Interviewers reward honesty and recovery.

1. Restate the sub-problem in your own words.
2. Relate it to something you know (a LeetCode pattern, a system you have used at work).
3. Propose a simple v1, then one optimisation if scale demands it.

How this connects to your DSA prep

The same skills from LeetCode transfer. Hash maps become caches and indexes. BFS becomes message propagation. Heaps become priority queues for task scheduling. If you have been grinding patterns on this site, you already have the algorithmic vocabulary — system design is about applying it at warehouse scale with networking and storage in the mix.

Next in this series: case studies (URL shortener, rate limiter, news feed, chat, notifications, file storage, typeahead) and fundamentals (caching, SQL vs NoSQL, load balancing, API design, unique IDs, message queues). Practise one design per week out loud.

A sample opening (first three minutes)

Here is dialogue that signals competence. Interviewer: "Design a URL shortener." You: "Before I draw boxes, let me clarify scope. Are we building a consumer product like bit.ly, or an internal link service for one company? Do we need analytics on clicks, custom aliases, or expiration? For scale, should I assume millions or billions of links per month?" That opening buys trust and prevents you from designing the wrong system.

Then: "I will assume 100 million new links per month, read-heavy traffic, sub-100ms redirects, and no login requirement for v1. I will start with a simple API, PostgreSQL for storage, Redis for hot redirects, and discuss scaling if we have time." You have not drawn anything yet, but the interviewer knows you are structured.

Common mistakes that fail candidates

• Jumping to microservices before proving you need them — a monolith with a cache often passes.
• Naming technologies without explaining why — "we use Kafka" is worthless without the event flow.
• Ignoring the write path on read-heavy systems — creation and redirect have different bottlenecks.
• Forgetting failure modes — what happens when Redis or the database is unavailable?
• Never checking back with the interviewer — treat it as a design review, not a solo exam.

Tools that help you practise

Use Excalidraw or a whiteboard app and time yourself. Record a 45-minute mock and watch for long silences. Read one case study per week on this site, then redesign it from memory 48 hours later. Pair with our From LeetCode Patterns to Real Systems article if DSA is your stronger side — it maps hash maps to indexes, BFS to fan-out, and heaps to schedulers.

How interview difficulty maps to level

Match your preparation to the roles you apply for. A .NET developer interviewing for a product company at mid-level should nail URL shortener + rate limiter + caching — those three cover the majority of loop questions.

Whiteboard layout that interviewers can follow

Divide the board into three zones: left = requirements and estimates (bullets, numbers), centre = architecture diagram (left-to-right data flow), right = deep dive detail (schema, cache keys, one sequence diagram). Interviewers photograph the board or share the Excalidraw link — a messy board hurts even good ideas. Label every arrow: "HTTPS", "async event", "read replica".

Start the diagram only after requirements. Candidates who draw AWS icons first look like they memorised a blog post. Candidates who write "POST /urls → validate → DB insert → return short URL" look like engineers.

Questions to ask every interviewer

• What scale should I design for — thousands, millions, or billions of users?
• Is this mobile-first, web-only, or API for third parties?
• What consistency level is acceptable — can reads be stale by a few seconds?
• Are we optimising for time-to-market or maximum scalability?
• Should I include analytics, admin tools, or stick to core user flows?

Asking two or three of these is enough. Write the answers on the board — they become constraints that justify your later decisions.