After this lesson, you will be able to: Explain what system design is, why it matters, and the questions a senior engineer asks before writing code.
System design is the work of choosing the components, boundaries, and data flow that determine whether your system will scale, survive, and stay maintainable. It's the single most-tested topic in mid-to-senior engineering interviews, and the most under-taught in school.
This is a free introductory lesson. No purchase required.
Programming: given a problem, write code that solves it. System design: given a problem, decide what to build, in what shape, talking to what, with what data, surviving what failures. The code is the LAST step. A senior engineer spends more time on system design than on writing code. The skill is recognizing the design decisions hidden in 'just go build it'.
1. Who uses it? (5 users vs 5M users is a 6-order-of-magnitude difference.) 2. What's the read/write ratio? (1000:1 reads/writes lets you cache aggressively; 1:1 doesn't.) 3. What does failure cost? (Tweet failing to post vs payment failing.) 4. What's the latency budget? (Real-time chat vs nightly batch.) 5. What's the data shape? (Relational vs document vs time-series.) 6. What's the deploy frequency? (Hourly deploys vs quarterly releases.) Answering these BEFORE drawing boxes is what separates senior from junior.
Clients (browsers, mobile apps, other services). Servers (web servers, application services, background workers). Data stores (databases, caches, object stores, queues). Connectors (load balancers, API gateways, CDNs, message buses). Every system you'll design is some combination of these four. Learning the catalog of each unlocks the design vocabulary.
Standard 45-minute structure: 5 min, clarify requirements (functional + non-functional). 5 min, capacity estimation (users / RPS / data volume). 10 min, high-level design (draw the boxes). 15 min, deep dive on 1-2 components the interviewer cares about. 10 min, bottlenecks, tradeoffs, alternatives. Most candidates fail by skipping clarification and jumping to boxes.
Jumping to a tech stack before clarifying requirements. Picking microservices for everything because they sound senior. Skipping capacity estimation. 'How many users' is the question that decides everything else. Treating availability and consistency as both-or-nothing rather than a slider. Failing to discuss what BREAKS in your design. Acknowledging failure modes is what makes the design credible.
Pick the most senior move.