SD notes

Introduction to System Design

Beginner · 7 min read · updated 29 October 2026

Quick answer

What is system design?

System design is deciding how the parts of a software system fit together to meet its requirements: which components exist, how requests flow between them, where data lives and how the whole stays fast and available as load grows. Interviews test it by asking you to design a real product end to end.

On this page

A request's life
HLD vs LLD
Requirements come first
Back-of-the-envelope estimation
Latency numbers worth knowing
A framework for the interview
Interview questions
Common questions

System design is choosing the parts of a system and how they work together, so it meets its requirements at the scale it must serve.

A request's life

DNS turns a name into an IP address (cached by browser and OS).
The app server runs the logic; it should keep no state of its own.
The database holds the state; it is usually the hardest part to scale.
Every arrow is a network round trip — each costs time.
Real systems add pieces on this path: a load balancer, a cache, a CDN.

A request's life: DNS, the app server, the database and back

A user opens the site. The browser has a name, not an address, so before anything else it must find which machine answers for that name.

0:01 / 0:20Step 1 of 7

Transcript · 7 steps

HLD vs LLD

	High-level design (HLD)	Low-level design (LLD)
Scope	The whole system	One component
Artefacts	Boxes and arrows, data flow	Classes, interfaces, schemas
Questions	Where does data live? How does it scale?	Which class owns this? Which pattern?
Interview	"Design a URL shortener"	"Design a parking lot's classes"

Requirements come first

Functional: what the system does — features, inputs, outputs.
Non-functional: how well — latency, availability, throughput, durability, consistency, cost.
Ask about both before drawing anything; agree what is out of scope.
Non-functional targets pick the architecture: a 99.99% target needs redundancy everywhere, a 10 ms target needs caching.

Functional vs non-functional requirements, sorted for a URL shortener

A design starts by pinning down requirements. Here are six for a URL shortener, still unsorted.

0:01 / 0:20Step 1 of 7

Transcript · 7 steps

Back-of-the-envelope estimation

QPS = daily users × requests per user ÷ 86,400 seconds.
Peak = average × a peak factor (often 2–5×; state your assumption).
Storage = writes per day × bytes per write × days kept.
Also worth a line: read/write ratio, bandwidth (QPS × response size), memory for a cache of the hot set.
Round to friendly numbers: 86,400 ≈ 100,000 is fine for an order of magnitude.

Back-of-the-envelope: QPS and storage from four assumptions

An estimate starts from stated assumptions. Say them out loud — the interviewer cares about the reasoning more than the digits.

0:01 / 0:18Step 1 of 7

Transcript · 7 steps

Latency numbers worth knowing

Approximate orders of magnitude, not benchmarks — hardware varies.
Memory: nanoseconds. SSD: around a hundred microseconds. Same-datacenter round trip: around half a millisecond.
Spinning-disk seek: milliseconds. Cross-ocean round trip: about a hundred milliseconds or more.
Lessons: keep hot data in memory, read sequentially, batch work, and put data near users.

Latency numbers: orders of magnitude every design leans on

A reference to the CPU's L1 cache takes about a nanosecond. The numbers here are rough, widely quoted orders of magnitude — hardware varies.

0:01 / 0:21Step 1 of 7

Transcript · 7 steps

A framework for the interview

Clarify requirements, users and scale (5 minutes).
Estimate QPS, storage and bandwidth.
Sketch the high-level design: clients, services, data stores.
Deep dive into one or two components the interviewer cares about.
Wrap up with bottlenecks, failure modes and trade-offs.

Interview questions

What do you ask first? The features in scope, who the users are, the scale, and the latency and availability targets.
How many seconds are in a day? 86,400 — round to 100,000 for quick estimates.
Why is the database usually the bottleneck? App servers are stateless and easy to add; the data has to stay correct in one place, which is harder to split.
What is the difference between availability and durability? Availability is whether the system answers right now; durability is whether stored data survives failures.

Next: Scalability

Common questions

What is the difference between HLD and LLD?

High-level design (HLD) is the architecture: the components, how they talk, where data is stored and how it scales. Low-level design (LLD) is inside one component: classes, interfaces, database schemas and algorithms. System design interviews are mostly HLD; machine-coding rounds are LLD.

What are functional and non-functional requirements?

Functional requirements say what the system does, such as shortening a URL or sending a message. Non-functional requirements say how well it does it: latency, availability, throughput, durability, consistency and cost. The non-functional ones usually decide the architecture.

How do you calculate QPS in a system design interview?

Multiply daily active users by requests per user per day, then divide by 86,400 seconds in a day for the average. Multiply by a peak factor, often two to five times, for the load you must actually handle. Round freely; the order of magnitude is what matters.

How do I start a system design interview?

Clarify requirements first: the features in scope, the users and scale, and the non-functional targets. Then estimate load and storage, sketch a high-level design, go deep on one or two components, and finish with bottlenecks and trade-offs.

Why do latency numbers matter in system design?

They tell you where time goes. Memory is nanoseconds, a disk or network round trip is micro- to milliseconds, and a cross-ocean round trip is about a hundred milliseconds or more. Knowing that gap explains why designs cache, batch and avoid round trips.

Introduction to System Design: Requirements to Estimates

System design basics for interviews: a request's life, HLD vs LLD, functional vs non-functional requirements, back-of-the-envelope estimates and latency.

Subject: System Design
Level: Beginner
Reading time: 7 min
Updated: 2026-10-29

What is system design?

System design is choosing the parts of a system and how they work together, so it meets its requirements at the scale it must serve.

A request's life

DNS turns a name into an IP address (cached by browser and OS).
The app server runs the logic; it should keep no state of its own.
The database holds the state; it is usually the hardest part to scale.
Every arrow is a network round trip — each costs time.
Real systems add pieces on this path: a load balancer, a cache, a CDN.

A request's life: DNS, the app server, the database and back.

A user opens the site. The browser has a name, not an address, so before anything else it must find which machine answers for that name.
The browser asks DNS, the internet's phone book, for the domain's IP address. Browsers and operating systems cache the answer, so later visits skip this trip.
DNS answers with an IP address. Now the browser knows where to send the real request.
The HTTP request reaches the app server, which runs the business logic — checks the session, decides what data the page needs.
The server asks the database for the rows. The database is where the state lives; the server itself keeps none.
The rows come back and the server turns them into a response — JSON for an API, HTML for a page.
The response reaches the browser: 6 network hops, 3 round trips. Each one costs time, which is why designs cache answers and cut trips.

HLD vs LLD

	High-level design (HLD)	Low-level design (LLD)
Scope	The whole system	One component
Artefacts	Boxes and arrows, data flow	Classes, interfaces, schemas
Questions	Where does data live? How does it scale?	Which class owns this? Which pattern?
Interview	"Design a URL shortener"	"Design a parking lot's classes"

Requirements come first

Functional: what the system does — features, inputs, outputs.
Non-functional: how well — latency, availability, throughput, durability, consistency, cost.
Ask about both before drawing anything; agree what is out of scope.
Non-functional targets pick the architecture: a 99.99% target needs redundancy everywhere, a 10 ms target needs caching.

Functional vs non-functional requirements, sorted for a URL shortener.

A design starts by pinning down requirements. Here are six for a URL shortener, still unsorted.
"Shorten a long URL": It is something the system does for a user, so it is functional.
"99.9% availability": It says how well, not what: 99.9% still allows about 8.76 hours of downtime a year, so it is non-functional.
"Redirect a short link": Following a short link to its target is a feature — another functional requirement.
"Redirect in < 100 ms": A latency target constrains the same feature without adding one: non-functional, and it shapes the design.
"Links expire on a date": Expiry is behaviour a user can ask for, so it joins the functional list.
A throughput target is a scale requirement — non-functional, and the input to the estimate. Sorted: 3 functional, 3 non-functional — the second list is what drives the architecture.

Back-of-the-envelope estimation

QPS = daily users × requests per user ÷ 86,400 seconds.
Peak = average × a peak factor (often 2–5×; state your assumption).
Storage = writes per day × bytes per write × days kept.
Also worth a line: read/write ratio, bandwidth (QPS × response size), memory for a cache of the hot set.
Round to friendly numbers: 86,400 ≈ 100,000 is fine for an order of magnitude.

Back-of-the-envelope: QPS and storage from four assumptions.

An estimate starts from stated assumptions. Say them out loud — the interviewer cares about the reasoning more than the digits.
10M daily users making 10 requests each is 100M requests a day.
A day has 86,400 seconds, so the average load is about 1,157 queries per second — call it 1.2K.
Traffic is not flat. With an assumed peak of 3× the average, the system must serve about 3,472 QPS.
If 10% of requests write data, that is 10M writes a day; the rest are reads, so this is read-heavy.
At about 1 KB per write, storage grows by 10 GB a day (decimal units keep the arithmetic easy).
Over 5 years that is about 18.3 TB before replicas and indexes — enough that how to copy and split the data becomes part of the design.

Latency numbers worth knowing

Approximate orders of magnitude, not benchmarks — hardware varies.
Memory: nanoseconds. SSD: around a hundred microseconds. Same-datacenter round trip: around half a millisecond.
Spinning-disk seek: milliseconds. Cross-ocean round trip: about a hundred milliseconds or more.
Lessons: keep hot data in memory, read sequentially, batch work, and put data near users.

Latency numbers: orders of magnitude every design leans on.

A reference to the CPU's L1 cache takes about a nanosecond. The numbers here are rough, widely quoted orders of magnitude — hardware varies.
Main memory reference: ~100 ns, roughly 100× the rung above. Missing the CPU cache and going to RAM.
SSD random read: ~100 µs, roughly 1,000× the rung above. Leaving memory for storage is the first big jump.
Round trip in a datacenter: ~500 µs, roughly 5× the rung above. One network hop to a cache or database nearby.
Disk seek (spinning HDD): ~10 ms, roughly 20× the rung above. A moving head, which is why random reads on spinning disks hurt.
Round trip across an ocean: ~150 ms, roughly 15× the rung above. Light in fibre takes time, which is why CDNs keep copies near users.
From the top rung to the bottom spans about 8 orders of magnitude. Memory answers in nanoseconds, disks and networks in micro- to milliseconds: keep hot data in memory and avoid round trips.

A framework for the interview

Clarify requirements, users and scale (5 minutes).
Estimate QPS, storage and bandwidth.
Sketch the high-level design: clients, services, data stores.
Deep dive into one or two components the interviewer cares about.
Wrap up with bottlenecks, failure modes and trade-offs.

Interview questions

What do you ask first? The features in scope, who the users are, the scale, and the latency and availability targets.
How many seconds are in a day? 86,400 — round to 100,000 for quick estimates.
Why is the database usually the bottleneck? App servers are stateless and easy to add; the data has to stay correct in one place, which is harder to split.
What is the difference between availability and durability? Availability is whether the system answers right now; durability is whether stored data survives failures.