System Design Interviews: A Beginner's Framework

System design interviews ask you to design a large system, such as a URL shortener, a chat app or a news feed, in about 45 minutes. There's no single correct answer. Interviewers are judging how you approach an open-ended problem: whether you ask the right questions, make reasonable decisions and explain the trade-offs.

They usually appear for mid-level and senior roles, though some companies include a lighter version for juniors.

The framework#

Use the same steps every time so you never freeze. Rough timings for a 45-minute interview are in brackets.

1. Clarify requirements (5 minutes)#

Never start drawing straight away. Ask about:

• Functional requirements: what must the system do? For a URL shortener: create short links, redirect, maybe custom aliases and expiry.
• Non-functional requirements: scale, latency, availability, consistency. Should redirects be very fast? Can a link ever be lost?
• Out of scope: agree what you won't cover (for example analytics dashboards).

Write the requirements down where the interviewer can see them.

2. Estimate scale (3–5 minutes)#

Rough numbers guide your design. For example:

• 100 million new links per month means about 40 new links per second on average.
• If each link is read 100 times, that's about 4,000 redirects per second. The system is read-heavy.
• At around 500 bytes per link, 100 million links per month is about 50 GB per month of storage.

Round generously. The point is to know whether you need one database server or many, and whether caching matters. (It does here.)

3. Define the API (5 minutes)#

POST /links        { "url": "https://…", "alias": "optional" }  → { "short": "abc123" }
GET  /{short}      → 301/302 redirect to the original URL

A clear API keeps the rest of the discussion grounded.

4. Design the data model (5 minutes)#

links: short_code (primary key), original_url, created_at, expires_at, owner_id

Then discuss the choice of database. For simple key-based lookups at high read volume, a key-value store or a relational database with a primary-key index can both work. Explain why you'd pick one.

5. Draw the high-level design (10 minutes)#

A typical starting point:

Client → Load balancer → App servers → Cache (e.g. Redis) → Database

Walk through both main flows: creating a link and following a link. Explain where each request goes.

6. Deep dive (10–15 minutes)#

The interviewer will usually steer you to one or two areas. Common ones:

• Generating short codes: random strings with collision checks, or encoding an auto-incrementing ID in base62. What are the trade-offs?
• Caching: cache popular links; what eviction policy, and what happens on a cache miss?
• Scaling the database: read replicas, then partitioning (sharding) by key if needed.
• Reliability: what happens when a server or the cache fails?

7. Discuss trade-offs and bottlenecks (5 minutes)#

Finish by naming the weak points and how you'd address them: single points of failure, hot keys, rate limiting against abuse, and monitoring. Showing that you know the limits of your design is a strong signal.

Core concepts to learn#

You don't need to know everything, but you should be comfortable explaining:

• Load balancing and horizontal scaling
• Caching (where to cache, invalidation, eviction)
• Databases: SQL vs NoSQL, indexes, replication, partitioning
• Consistency vs availability trade-offs
• Message queues for asynchronous work
• CDNs for static content
• Rate limiting and idempotency

The free, open-source System Design Primer is a widely used starting point for these topics.

Practise with classic problems#

Work through these with the framework above, out loud and ideally with a friend:

1. URL shortener
2. Rate limiter
3. Chat application
4. News feed
5. File storage service
6. Notification system

Common mistakes#

• Jumping into components without clarifying requirements.
• Naming technologies without explaining why ("I'll use Kafka" for no reason).
• Designing for enormous scale when the requirements don't need it.
• Going silent. Think out loud; the conversation is what's being assessed.
• Ignoring the interviewer's hints. If they steer you somewhere, follow.

Key takeaways#

• Follow the same steps every time: requirements, estimates, API, data model, high-level design, deep dive, trade-offs.
• Use rough numbers to justify decisions.
• Explain the why behind every choice and admit trade-offs.
• Practise classic problems out loud.

See where system design fits in the overall interview process, and what it means for your growth in junior to senior developer.

#interviews#system design