System design in one lesson

Why it matters

Writing code answers "how do I make this work". System design answers "how do I make this keep working when a million people use it, a server dies at 3 a.m., and the product team adds three features a month". It is the skill that separates engineers who ship features from engineers who are trusted with a system, and it is tested in nearly every senior-level interview because it is hard to fake.

The idea

A system is a set of components (clients, servers, databases, caches, queues) connected by the data that flows between them. System design is deciding which components to use, how to connect them, and which trade-offs to accept so the system meets two kinds of requirement.

Functional requirements are what the system does: users can post, follow, see a feed. Non-functional requirements are how well it does it, and they drive almost every design decision:

Every component in the toolbox exists to move one of those numbers, and every one of them costs something on another axis. A cache lowers latency and raises staleness. Replication raises availability and complicates consistency. Sharding raises write capacity and breaks cross-shard transactions. The rest of this track is a tour of those levers.

The method

Good designers follow the same loop whether on a whiteboard or in a design doc:

1. 1

   Clarify requirements

   Functional first, then the non-functional targets with numbers. Ask about read-to-write ratio and the consistency the product can tolerate.
2. 2

   Estimate

   Users, requests per second, data size, bandwidth. Rough is fine; an order of magnitude decides the architecture.
3. 3

   Draw the high-level design

   Boxes and arrows for the main request paths. Name the data store and why.
4. 4

   Deep dive the hard parts

   The hot path, the bottleneck, the failure mode. Make the trade-offs explicit.
5. 5

   Revisit under change

   What breaks at 10x? What happens when this box dies? Adjust, and say what the adjustment costs.

Trade-offs

The discipline has one meta-trade-off: simplicity against capability. Every component you add is something that can fail, must be monitored and has to be explained to the next engineer. The best design is usually the simplest one that meets the stated numbers, with a clear path to the next order of magnitude.

In an interview

Say the method out loud in the first minute: "Let me confirm the functional requirements, then pin down scale and the non-functional targets, then draw the high-level design and go deep on the hardest part." Interviewers relax when they hear structure. Then, for every component you draw, say what it buys and what it costs. That habit alone moves a candidate from mid to senior in the grader's notes.