How to Approach System Design

#Introduction

System design is deciding how the pieces of a system — clients, services, databases, caches, queues — fit together to meet its requirements at the required scale, reliability and cost.

#A Repeatable Framework

Step 1 — Clarify Requirements

Functional requirements — what the system does:

• "Users can shorten a long URL and get a short link."
• "Visiting the short link redirects to the original URL."
• "Links can have an optional expiry date."

Non-functional requirements — how well it does it:

Step 2 — Estimate Scale

Rough numbers decide the architecture: 10 requests per second fits on one server; 100,000 needs caching, sharding and many instances. See Back-of-the-Envelope Estimation.

Step 3 — Define the API

POST /api/urls            { longUrl, expiresAt? }  →  201 { shortUrl }
GET  /{code}                                        →  301/302 Location: longUrl
GET  /api/urls/{code}/stats                         →  200 { clicks, … }

The API pins down exactly what the system must support.

Step 4 — Design the Data Model

What entities exist, how they're accessed, and which database fits the access patterns:

url_mapping(code PK, long_url, user_id, created_at, expires_at)

Step 5 — High-Level Design

Draw the main components and the request flow:

Walk through the main use cases on the diagram: "A create request goes to an app server, which generates a code, stores it, and returns the link…"

Step 6 — Deep Dives

Pick the hardest or most interesting parts — often guided by the interviewer:

• How are short codes generated without collisions?
• How do we serve 100,000 redirects per second with low latency?
• How is data partitioned as it grows?
• What happens when a database node fails?

Step 7 — Bottlenecks and Trade-offs

Identify single points of failure, hot spots and scaling limits, and say how you'd address them — plus what you'd monitor.

#The Building Blocks

The rest of this topic covers each building block:

And two full worked designs: a URL shortener and a notification system.

#Key Takeaways

• System design interviews test structured thinking and trade-offs, not one correct answer.
• Follow a framework: requirements → estimates → API → data model → high-level design → deep dives → trade-offs.
• Separate functional from non-functional requirements and agree on scope.
• Let estimates drive the design; justify every component.
• Talk through failures, bottlenecks and what you'd monitor.