What Is System Design?

beginner 0-2 YOE system-design interviews fundamentals

System design is the process of defining the architecture, components, and data flow of a system to meet specific requirements. Think of it like being an architect for software — we decide what pieces we need, how they talk to each other, and how the whole thing holds up when millions of people use it.

Why Do Companies Ask System Design Questions?

Coding interviews test if we can write correct code. System design interviews test if we can think big.

At 3+ years of experience, companies expect us to do more than just write functions. They want to know:

  • Can we break a vague problem into concrete pieces?
  • Can we think about trade-offs (there’s no perfect answer)?
  • Can we communicate our thought process clearly?
  • Do we understand how real-world systems actually work?

The only difference between a coding interview and a system design interview is this: coding has a “right answer,” system design does not. It’s a conversation, not a test.

What Interviewers Actually Look For

Here’s what most people get wrong — interviewers are NOT looking for the “perfect architecture.” They’re evaluating:

  1. Communication — Can we explain our thinking clearly?
  2. Problem breakdown — Can we go from vague to specific?
  3. Trade-off awareness — Do we know why we picked X over Y?
  4. Breadth of knowledge — Do we know what tools exist?
  5. Depth when needed — Can we dive deep into one area?

A candidate who designs a simpler system but explains trade-offs well will beat someone who draws a complex diagram but can’t explain why.

The Journey: Single Server to Distributed System

From Simple to Scaled
Stage 1: Single server does everything
  └── App + DB + Files all on one machine
        ↓ traffic grows...
Stage 2: Separate the database
  └── App Server ←→ Database Server
        ↓ more traffic...
Stage 3: Add a load balancer + multiple app servers
  └── LB → [Server 1, Server 2, Server 3] → DB
        ↓ even more traffic...
Stage 4: Add caching, CDN, message queues, DB replicas
  └── The full distributed system

This is basically what system design is about — understanding when and why we move from one stage to the next. We don’t need a distributed system for 100 users. But we do need to know how to build one for 100 million.

When Does System Design Matter?

  • Junior roles (0-2 YOE): Rarely asked. Focus on coding.
  • Mid-level (3-5 YOE): Common. Expected to know the building blocks.
  • Senior+ (5+ YOE): Critical. Expected to lead design discussions and make architectural decisions.

Even if we’re not interviewing, understanding system design makes us better engineers. We start seeing why things are built the way they are.

Key Takeaway

System design isn’t about memorizing architectures. It’s about understanding building blocks (load balancers, caches, queues, databases) and knowing when to use what. The rest of this collection covers exactly that — one building block at a time.