What Is System Design? A Beginner's Introduction

This is the most under-rated distinction in system design, and it is where most weak interviews are lost in the first five minutes.

Consider design a URL shortener. The functional requirements are trivial: shorten a URL, redirect a short code. Now change one non-functional number:

• 100 requests/day → a single Postgres table and one small server. You are done in three minutes.
• 100,000 requests/second, global, 99.99% → CDN edge redirects, a distributed key-value store, pre-generated ID ranges per host, multi-region replication, and an asynchronous analytics pipeline.

Same features. Completely different system. That is why you never start drawing until you have numbers.

The six non-functional questions to always ask

1. 1

   Scale

   How many users, and how many requests per second at peak? Peak is typically 2–3× the daily average.
2. 2

   Read/write ratio

   100:1 read-heavy means caching and replicas. 1:1 or write-heavy means partitioning and write-optimised storage.
3. 3

   Latency target

   Always ask for the percentile. 'Fast' is meaningless; 'p99 under 200 ms' is a design constraint.
4. 4

   Availability target

   99.9% is 43 minutes of downtime a month. 99.99% is 4.3 minutes and needs multi-AZ with automated failover.
5. 5

   Consistency requirement

   Can a user briefly see stale data? For a like count, yes. For an account balance, no. This single answer picks your database.
6. 6

   Durability and retention

   Can you ever lose a write? How long must data live, and does it need to be deletable on request?

Latency and throughput are not the same knob

A useful analogy: a motorway. Latency is how long your car takes to travel it. Throughput is how many cars per hour arrive at the other end. Add lanes and throughput rises while your personal travel time is unchanged. Raise the speed limit and latency drops. They are related, but you tune them with different tools.

Batching makes this concrete: writing 1,000 rows one at a time might give you 5 ms per write and 200 writes/second. Batching them into groups of 100 might give you 40 ms per batch - worse latency for the last row in a batch - but 2,500 writes/second. Throughput up 12×, latency up 8×.

Availability in practice

Each extra nine roughly multiplies cost and operational complexity. Part of being senior is saying “three nines is enough for this product” rather than reflexively reaching for five.

1. 1

   0–5 min · Clarify and scope

   Restate the problem. List 3–5 functional requirements and explicitly park the rest. Get numbers: DAU, read/write ratio, latency and consistency targets. Write them in a corner of the board and refer back to them later - that call-back is a strong senior signal.
2. 2

   5–10 min · Estimate and define the contract

   Back-of-envelope: QPS, storage per year, bandwidth. Then sketch 3–4 API endpoints and the core entities. This is where you decide what the system stores, which constrains everything downstream.
3. 3

   10–20 min · High-level design

   Draw client → edge → service → storage, end to end, and walk one write and one read through it out loud. Get to a complete design early, even a naive one. A finished simple design beats a beautiful half-design every time.
4. 4

   20–35 min · Deep dive

   The interviewer will pick a component: 'how does the feed get generated?', 'what happens if this shard is hot?'. This is the highest-signal section. Go two layers deeper than you think is necessary and name concrete technologies with reasons.
5. 5

   35–45 min · Scale, fail, and wrap

   Proactively find your own bottleneck and fix it. Then discuss failure: what happens when the cache dies, when a region goes down, when the queue backs up. Close with a one-sentence summary of the key trade-off you chose.

Drive the conversation

The strongest candidates narrate their own agenda: “I'll spend two more minutes on requirements, then draw the write path, then we can go deep wherever you'd like.” This turns the interview from an interrogation into a design review - which is exactly the collaboration the interviewer is trying to simulate.

Almost every system design answer is assembled from the same small kit. Learn what each piece is for and design becomes composition rather than invention.

The order things usually get added

1. One server, one database. Serves surprisingly many products.
2. Split the database onto its own machine, so a traffic spike does not starve it of CPU.
3. Add a load balancer and a second app server. Now you survive one machine dying.
4. Add a cache. Usually the single largest latency win you will ever get.
5. Add a CDN for static assets and media.
6. Add read replicas when read load saturates the primary.
7. Add a queue and workers to push slow work out of the request path.
8. Shard the database when a single primary can no longer take the write volume.
9. Split services only when team coordination cost, not machine cost, becomes the bottleneck.