System design interview basics: a simple framework and example
System design interviews are open-ended on purpose. You are judged on how you clarify, simplify and reason about trade-offs, not on a single correct diagram.
Sample candidate (fictional): Sam, a software engineer with three years of experience designing a URL shortener in a practice session. Every example answer is invented for practice. Rewrite them with your own facts.
A framework and a worked example
Sam designs a URL shortener. All numbers are rough practice assumptions, not measurements: 100 million new links a month and a 10:1 read-to-write ratio.
Writes per second: 100 million over about 2.6 million seconds is roughly 40 per second. Reads are about 400 per second. That is small enough for a single database to handle with caching, and Sam says so before adding complexity.
- Clarify requirements: what must it do, who uses it, how big, what matters most (latency, availability, cost).
- Estimate scale: requests per second, storage per year, read versus write.
- Sketch the simple version first: client, API server, database.
- Define the data model and the main API calls.
- Find bottlenecks and add components only when a number justifies them, such as a cache or replicas.
- Discuss trade-offs and failure cases, and say what you would build first.
Common questions
-
How do I begin a system design question?
How to answer
Ask what the system must do and what it need not do. Write down two or three functional and non-functional requirements.
Example answer
For the URL shortener: users can create a short link and open it to be redirected. Non-functional: redirects should be fast and the service should stay up. I will treat analytics and custom aliases as optional extras.
-
How do I estimate scale?
How to answer
Use round numbers. Convert monthly totals to per-second, separate reads from writes and estimate storage per year.
Example answer
100 million links a month is about 40 writes per second. At 500 bytes a record, that is about 600 GB a year. That fits comfortably on one modern database for now.
-
How should I design the data model?
How to answer
List the main entities, the key fields and how you will look them up. Pick the key that matches your main read path.
Example answer
One table keyed by short code: code, long URL, created time, optional expiry. Reads look up by code, so a key-value style lookup is enough.
-
SQL or NoSQL?
How to answer
Decide from access patterns and consistency needs, not fashion. Either can work; explain why you pick one.
Example answer
Our access pattern is lookup by key with simple records, so a key-value store fits, but a relational database would also work at this size. I would pick what the team already runs well.
-
When do I add a cache?
How to answer
When reads dominate and the same items are requested repeatedly, and a number shows the database would struggle or latency matters.
Example answer
Redirects are read-heavy and a few links are very popular, so a cache in front of the database will cut latency. I would use a time-to-live and handle cache misses by reading from the database.
-
How do I generate unique IDs or short codes?
How to answer
Explain two options and their trade-offs: a counter encoded in base 62, or random codes with a collision check.
Example answer
A counter encoded in base 62 gives short, unique codes but the sequence is guessable and needs a shared counter. Random codes avoid that but need a collision check. I would start with random codes plus a unique constraint.
-
How do I scale reads and writes?
How to answer
Start with the simplest step: replicas for reads, then partitioning when a single node can no longer hold the data or write load.
Example answer
At 400 reads per second, a cache plus a replica is enough. If we grew a hundred times, I would partition the table by short code so each node holds part of the keys.
-
What about availability and failures?
How to answer
Name the single points of failure and how you would remove them: more than one server, health checks, replicas, backups.
Example answer
Run at least two API servers behind a load balancer, keep a replica of the database, and take regular backups. If the cache is down, requests fall back to the database, with slower responses.
-
How do I wrap up a design interview?
How to answer
Summarise the design in a few lines, name the main trade-offs and what you would improve with more time.
Example answer
Summary: stateless API servers, a key-value store, a cache for hot links. Trade-off: random codes need a collision check. With more time I would add rate limiting and basic abuse checks.
Practise it out loud
Say your answers to a mock question, then tighten them. Try it free in your browser, or build the resume the questions will come from.