How to Think Like a System Designer

Before you place a single box on a canvas, a system designer answers two questions: "what does this system need to do?" and "how much of it, how fast, for how many people?" Skipping either question is the single most common reason a design falls apart, whether under interview scrutiny or real production traffic.

Before an architect draws a floor plan, they ask questions. How many people will live here? What is the budget? Does anyone use a wheelchair? What is the climate? A house for two and a hotel for 400 are not the same building with more rooms: they need different foundations, lifts and fire exits. The questions come first because the answers decide the structure. System design works the same way.

• -What the client wants the building to do is the functional requirements.
• -How many people, how safe, how durable is the non-functional requirements.
• -Measuring the plot and counting the occupants is estimation.
• -The floor plan is the high-level design.
• -The beam that will fail first under load is the bottleneck.
• -Choosing a cheaper material and accepting its limits is the trade-off.

Functional requirements are the verbs: "users can post a photo," "the system sends a notification within 5 seconds," "an admin can ban a user." They describe behavior. Non-functional requirements are the constraints those behaviors must survive: how many users, how many requests per second, what latency is acceptable, what happens during a traffic spike, what happens when a server dies. A design that nails the functional requirements but ignores the non-functional ones is a prototype, not a system.

• -Functional describes what the system does: features, user flows, business rules.
• -Non-functional describes how well it does it: scale, latency, availability, consistency, cost.
• -Non-functional requirements are what turn "a working demo" into "a system that survives Black Friday."

A system serving 1,000 users and a system serving 100 million users are not the same system with more servers bolted on; they are architecturally different. A single PostgreSQL instance is the right answer at the first scale and actively wrong at the second. That is why every serious design starts with rough, order-of-magnitude estimation: how many users, how many requests per second, how much data, growing at what rate. You do not need precision. You need to know whether you are building for a thousand users or a billion, because that decides everything downstream.

Here is what an estimate looks like in practice. Say you are asked to design the notification system for an app with 10 million daily users, and each user receives about 5 notifications a day. That is 10,000,000 x 5 = 50 million notifications a day. A day has 86,400 seconds, so the average is 50,000,000 / 86,400, about 580 per second. Traffic is not flat, so assume the peak is 5 times the average: roughly 2,900 per second. If each notification is stored for 30 days at about 1 KB, that is 50 GB a day and 1.5 TB in total.

What did the numbers tell you, before any box was drawn? About 3,000 messages a second at the peak is easy for a pool of workers fed by a queue, so the design does not need exotic machinery. The storage figure, 1.5 TB, is the part that grows, so you should decide early how long to keep notifications. And the real constraint will probably be the rate limits of the push services you send through. An estimate tells you where to look.

You do not need precision, only the right order of magnitude. If you are off by 30%, nothing changes. If you are off by a factor of 100, the whole architecture changes. For a longer list of reference numbers, the Wiki card below is a good one to keep open while you practice:

When you are handed a vague prompt, "design a notification system", resist the urge to start drawing boxes immediately. Instead, work through this sequence, which every chapter in this course implicitly follows:

Applied to the notification system, the five steps look like this. Clarify what kinds of notification are in scope and what is not. Estimate as above. Sketch client to API to queue to workers to push service. Name the bottleneck: the push service's limits and storage growth. State the trade-off, such as accepting that a notification may arrive a few seconds late in return for never blocking the sender.

• -1. Clarify functional scope: what must it do, and just as importantly, what is explicitly out of scope?
• -2. Estimate scale: users, QPS, data volume, growth rate.
• -3. Sketch the high-level flow: client to server to storage, in the simplest shape that could work.
• -4. Identify the bottleneck: which single piece will break first as scale grows?
• -5. Discuss the trade-off: what did you sacrifice (cost, consistency, complexity) to fix that bottleneck?

The chapter at the end of this module, How to Structure Any Design Answer, shows how to fit this loop into the time available in an interview.