Free lesson · System Design Fundamentals

What Is System Design?

Easy4 min readsystem-designhlddistributed-systems

Lesson 1.4 - What Is System Design?

The fourth lesson of Module 1.

"System design" gets used so loosely that it's worth pausing to define it precisely. It's not a programming language. It's not a framework. It's not a tool. It's an activity - the activity of deciding how the parts of a software system fit together, what technologies to use, what trade-offs to accept, and how the system behaves under load, under failure, and over time.

The Activity

Interactive animation: All six decisions, on one small feature: a like button.

When an engineer says "I'm doing system design," they mean: I'm making decisions about the architecture of a system before (or while) building it.

Concrete examples of system design decisions:

"Should user data live in PostgreSQL or DynamoDB?" - a storage decision
"Should we cache this endpoint, and if so, where?" - a performance decision
"Should services communicate synchronously (HTTP) or asynchronously (message queue)?" - a communication decision
"What happens when the payment gateway is down for 30 seconds?" - a reliability decision
"Can this system handle 10x traffic on Black Friday?" - a scalability decision
"Should we build this as one service or three?" - an architecture decision

None of these are coding questions. All of them shape the system more than any single function or class.

flowchart TD
    SD["System Design"]
    
    What["WHAT components?<br/>(database, cache, queue,<br/>load balancer, CDN)"]
    How["HOW do they connect?<br/>(sync, async, streaming,<br/>request-response)"]
    Why["WHY these choices?<br/>(trade-offs: consistency vs speed,<br/>cost vs durability,<br/>simplicity vs flexibility)"]
    When["WHEN does it break?<br/>(failure modes, bottlenecks,<br/>scaling limits)"]
    
    SD --> What
    SD --> How
    SD --> Why
    SD --> When

    style SD fill:#0064FF,stroke:#f59e0b,color:#000

A diagram showing the four questions system design answers. What components does the system need - databases, caches, queues, load balancers, CDNs? How do they connect - synchronously, asynchronously, via streaming, via request-response? Why these choices - what trade-offs are being accepted, such as consistency versus speed, cost versus durability, simplicity versus flexibility? When does it break - what are the failure modes, where are the bottlenecks, what are the scaling limits? System design is the discipline of answering all four questions for a given system, before or while building it.

Where System Design Shows Up

1. In your daily engineering work. Every time you add a feature that touches multiple services, choose a database, design an API, or plan for growth - you're doing system design. Mid-level and senior engineers do this constantly, whether they name it or not.

2. In design reviews. Most engineering organizations have formal or informal design review processes. An engineer proposes an architecture (usually in a document or a whiteboard session); peers critique it. The vocabulary of this course is the vocabulary of those reviews.

3. In technical interviews. FAANG companies and most well-funded startups include a system design interview round - typically 45-60 minutes, where a candidate designs a system (URL shortener, chat application, news feed, ride-sharing service) on a whiteboard while an interviewer probes their thinking. This is the highest-leverage interview round for mid-level and senior candidates. It's also the round with the least standardized preparation - unlike coding interviews (where LeetCode provides structure), system design interviews have no universally agreed-upon study path. This course is that path.

4. In career progression. The transition from mid-level to senior engineer is largely a transition from "I can build what's designed" to "I can design what needs to be built." System design competence is the skill that makes that transition possible. Above senior - at Staff and Principal levels - system design becomes the primary job function.

What System Design Is NOT

Interactive animation: Not a tool, not a diagram, not a job title. Something you do, not something you have.

It's not coding. System design operates at a higher abstraction - boxes and arrows, not functions and variables. Coding implements the design; the design decides what to code.

It's not memorizing architectures. "The Twitter architecture has a fan-out-on-write system for the timeline" is trivia. Understanding WHY fan-out-on-write works for Twitter (high read volume, bounded follower counts for most users) and when it DOESN'T work (celebrity accounts with millions of followers) - that's system design thinking.

It's not a single right answer. Every design question has multiple valid solutions with different trade-offs. "Use PostgreSQL" and "use DynamoDB" can both be correct for the same problem - they optimize for different things. The skill is articulating the trade-offs and making a defensible choice, not memorizing the "right" answer.

A Brandon Story: When I First Understood

I spent my first 4 years at IBM writing enterprise Java. I wrote code. Good code, tested code, well-structured code. But I never thought about the system - where the data lived, how it flowed, what happened under load, what happened when a server died. I didn't need to; someone else had designed the system, and I implemented pieces of it.

When I moved to Stripe and started building payment infrastructure, the design decisions suddenly mattered more than the code. "Should we store transaction records in Postgres or DynamoDB?" wasn't a preference - it determined the consistency model, the query patterns, the scaling path, and the failure modes for every downstream system. Getting the design wrong meant months of rework. Getting the code wrong meant a PR comment and a fix.

That was when I understood: the design is the highest-leverage work. A good design with mediocre code produces a working system. A bad design with excellent code produces a well-crafted failure.

Six Takeaways from This Lesson

System design is the activity of deciding how a system's parts fit together - what components, how they connect, why those choices, when it breaks.
It's not coding. It's the decisions that determine what gets coded.
It shows up everywhere: daily engineering, design reviews, interviews, career progression.
There's no single right answer. There are trade-offs. The skill is articulating them.
System design competence is the senior-engineer transition. From implementer to designer.
The design is the highest-leverage work. It determines the system's fate more than any single piece of code.

What's Next

Lesson 1.5 gives you a rapid-fire walkthrough of 30 concepts that will appear throughout the course - a vocabulary primer so unfamiliar terms don't slow you down in the modules ahead.

Back to System Design Fundamentals