The System Design Interview: A Step-by-Step Framework

A system design interview isn’t a test of whether you’ve memorised the architecture of a famous app. It’s a conversation that shows how you think: how you clarify a vague problem, make reasonable assumptions, choose trade-offs and communicate. A repeatable framework keeps you on track under pressure.

The framework at a glance

Step 1: Clarify requirements

Split requirements into two lists.

Functional: what the system does. For a URL shortener: create a short link, redirect to the original URL, optionally set expiry.

Non-functional: how well it does it. Latency targets, availability, consistency needs, durability, security and expected scale.

Ask questions: Who are the users? What matters most: speed, correctness or cost? What’s out of scope? Write the answers down; you’ll use them to justify decisions later.

Step 2: Estimate scale

Rough numbers guide every later choice. Estimate (our guide to back-of-the-envelope estimation has the handy numbers):

• Daily active users and requests per second (average and peak)
• The read-to-write ratio
• Storage needed over time
• Bandwidth

For example: 100 million new links a month is roughly 40 writes per second on average. If reads are 100 times writes, that’s about 4,000 reads per second, so this is a read-heavy system where caching will matter.

Step 3: Define the API

Sketch the key endpoints:

POST /links          { "url": "https://example.com/long", "expiresAt": null }
  -> 201 { "code": "a8Xk2", "shortUrl": "https://sho.rt/a8Xk2" }

GET  /{code}         -> 301 redirect to the original URL

Mention authentication, rate limits and idempotency where they matter.

Step 4: Data model

Choose what you store and where. For the URL shortener: a table mapping short codes to URLs, with created time, expiry and owner. Discuss the choice of database: a key-value lookup by code suits many NoSQL stores, but a relational database also works well at moderate scale. Explain the access pattern that drives your choice.

Step 5: High-level design

Draw the main path: clients, load balancer, stateless application servers, a cache, the database, and any queues or background workers. Walk through one request end to end: “A redirect request hits the load balancer, an app server checks the cache, falls back to the database on a miss, then returns a redirect.”

Step 6: Deep dives

Pick the parts that are hardest or riskiest, or follow the interviewer’s lead. Common deep dives:

• Caching: what to cache, invalidation and eviction; see our guide to caching strategies.
• Rate limiting: protecting the service from abuse; see rate limiting algorithms.
• Scaling the database: replication for reads, sharding for writes.
• Unique ID generation without collisions.
• Failure handling: retries, timeouts and what happens when a component goes down.

Step 7: Wrap up

Summarise the design, name the bottlenecks and single points of failure, and say what you’d do next with more time: monitoring, multi-region deployment or cost optimisation.

What interviewers look for

• Structured thinking: a clear process instead of jumping straight to boxes.
• Justified trade-offs: “I chose X because of Y requirement.”
• Communication: thinking aloud and checking in with the interviewer.
• Depth where it matters, rather than shallow coverage of everything.

Common mistakes

• Designing before clarifying requirements.
• Adding microservices, Kafka and Kubernetes without a reason.
• Ignoring the numbers from your own estimates.
• Going silent for long periods.
• Treating the interviewer’s hints as interruptions rather than guidance.

How to practise

Work through classic problems out loud: a URL shortener, a chat app, a news feed, a rate limiter, a file storage service. You can even rehearse with an AI assistant acting as interviewer; AIEmulate has prompt templates for interview practice.

Frequently asked questions

How long is a system design interview?

Typically 45 to 60 minutes. Adjust the time spent on each step, but keep the order.

Do I need to know specific technologies?

Understand categories (relational vs NoSQL databases, caches, queues, CDNs) and their trade-offs. Naming a specific product is fine if you can justify it.

What if I don’t know the answer to a deep-dive question?

Say what you know, reason from first principles and state assumptions. Honest reasoning scores better than bluffing.