What Is System Design? Start With Requirements

Two levels of design

• High-level design (HLD) is the big picture: boxes and arrows. "Clients talk to a load balancer (a server that shares requests between many servers), which talks to app servers, which use a cache and a database." This is what most system-design articles and interviews focus on.
• Low-level design (LLD) is the detail inside one box: classes (code blueprints), database tables, API endpoints (the URLs that a service offers) and algorithms (step-by-step methods).

This series is mostly about HLD, but we go into LLD when it matters, for example database schemas (the layout of tables) and API design.

The qualities every system is judged on

When people say a system is "good", they usually mean some mix of these qualities. Each one is a question you can ask about a system:

You cannot get the best score in all of them at once. Improving one often hurts another. That is why design is about trade-offs. Two terms are easy to confuse: availability is whether the system is up and answering, and reliability is whether the answers are correct.

Performance vs scalability

People often mix these two up, so let us separate them:

• A performance problem: the system is slow even for one user. Example: a page that takes 5 seconds because of a missing database index.
• A scalability problem: the system is fast for one user but gets slower as users grow. Example: a page that loads in 100 ms with 10 users but 10 seconds with 10,000, because every request competes for the same database.

Fixing performance usually means better code or queries. Fixing scalability usually means changing the architecture. Scalability means how well a system keeps working as the load grows.

Step one: requirements

Requirements come in two types.

1. Functional requirements: what the system does. These are the features, written from the user's point of view. For a URL shortener (a service that turns a long web address into a short one):

• A user can paste a long URL and get a short one.
• Visiting the short URL redirects to the long URL.
• A user can choose a custom alias (optional).
• Links can expire after a set time (optional).

Just as important is what is out of scope (not part of the work). For example: "We are not building user accounts or analytics dashboards in version 1." Saying this out loud stops the design from growing forever.

2. Non-functional requirements (NFRs): how well the system does it. These are the qualities from the table above, and they drive most architecture decisions. Difference in one line: functional says what the system does, non-functional says how well it does it. Examples:

• Scale: 100 million new links per month, 10 billion redirects per month.
• Latency: redirects should feel instant, under 50 ms for most users. (Latency is the time one request takes.)
• Availability: redirects must almost never fail. Creating links can accept a little downtime.
• Durability: saved data stays saved. A link, once created, must never be lost.
• Read/write ratio: about 100 redirects (reads) for every 1 link created (write), so it is very read-heavy.

Make requirements measurable

"The site must be fast and always up" sounds like a requirement, but it is not one. You cannot design for it or test it. Turn vague words into numbers:

We learn what these numbers mean in the next few lessons: latency percentiles, availability "nines" and estimation.

Constraints and assumptions

A constraint is something you cannot change. An assumption is something you guess is true. Write down both:

• Budget and team size (three engineers cannot run 40 microservices, which are many small separate services).
• Where users are (one country or worldwide?).
• Legal rules (data about EU users may need to stay in the EU).
• Deadlines.
• Assumptions like "the average post is 1 KB" or "20% of users are active daily".

Assumptions are fine. Hidden assumptions are dangerous. Write them down so that others can question them.

Thinking in trade-offs

Almost every decision in this series is a trade-off. Here are the ones you will meet again and again:

• Consistency vs availability: show slightly old data, or show an error? (Consistency means everyone sees the same, latest data.)
• Latency vs throughput: answer each request quickly, or group work into batches to do more in total? (Throughput is how much work is done per second.)
• Read speed vs write speed: keep extra copies of data to make reads fast, but make writes slower?
• SQL vs NoSQL (tables vs other kinds of databases), monolith vs microservices (one big program vs many small ones), build vs buy.
• Cost vs everything else: more servers, more regions (separate geographic locations) and more copies all cost money.

Reversible vs irreversible decisions. Some decisions are easy to undo, like changing a cache timeout. Others are very hard to undo, like choosing a database, a sharding key (the field used to split data across databases) or a public API format. Decide fast on the easy ones and think carefully about the hard ones.

Write decisions down. Many teams use short Architecture Decision Records (ADRs): one page saying what was decided, why, what other options were considered, and what trade-offs were accepted. Six months later, when someone asks "why did we pick PostgreSQL?", the answer is there.

Simple is a feature

Every new component (a cache, a queue, a new database) is one more thing that can break, one more thing to watch, and one more thing to learn. A design that meets the requirements with fewer parts usually beats a clever one. Many engineers call this "choosing boring technology". Well-known, well-understood tools let you spend your energy on the real product.