Introduction to System Design

What Is System Design?

System design is the process of defining the architecture, components, data flows, and interfaces of a system to satisfy a set of requirements. Where algorithms ask "how do I solve this computational problem efficiently?", system design asks "how do I build a system that solves this problem for millions of users, stays available when things fail, and can grow without a complete rewrite?"

These are fundamentally different questions. You can know every sorting algorithm cold and still struggle to design a URL shortener that handles 10 billion requests per day.

Why System Design Is Hard

Three things make system design hard:

1. There is no single correct answer. Unlike algorithms, where there's usually an optimal solution, system design involves tradeoffs. Every choice you make — SQL vs NoSQL, synchronous vs asynchronous, monolith vs microservices — is context-dependent. What's right for Twitter is wrong for a startup with 200 users.

2. Requirements are ambiguous. In the real world, requirements arrive underspecified. Clarifying them is part of the work. Good designers ask questions before drawing boxes.

3. Everything fails at scale. A system that works perfectly at 100 requests/second breaks in unexpected ways at 100,000 requests/second. Networks partition. Disks fill. Caches expire simultaneously (the thundering herd problem). Clocks drift. Designing for failure is not optional.

The Goal: Not Perfection, But Fitness

The goal of system design is to build a system that is:

• Correct — produces the right outputs
• Scalable — handles growth in load without redesign
• Available — serves requests even when parts fail
• Reliable — doesn't lose data or corrupt state
• Maintainable — can be understood, modified, and debugged by a team

Notice that these often conflict. Maximizing availability sometimes means accepting eventual consistency (not always correct). Maximizing scalability sometimes means accepting more operational complexity (harder to maintain). Design is the art of navigating these tensions.

First Principles of System Design

Separate concerns

Different parts of a system should be responsible for different things. A service that handles both user authentication and payment processing is harder to scale, test, and reason about than two services that each do one thing well.

Push work to where the data is

Network calls are expensive (latency, bandwidth). Computation is cheap. Move processing to where the data already lives — this is why databases have stored procedures and why CDNs cache content close to users.

Design for the bottleneck

At any given scale, one component limits system throughput. Find it. Fix it. Then find the next one. Don't optimize everything uniformly — 80% of the gains come from 20% of the work.

Make failure a first-class citizen

Every component can fail. Every network call can time out. Every disk can fill. Write systems that degrade gracefully: circuit breakers, retries with backoff, fallback values, bulkheads.

Prefer simple systems

Complexity is the enemy of reliability. Every additional component is a potential point of failure, an extra on-call page, and a piece of context that must live in engineers' heads. Add complexity only when its benefits are measured and clear.

A Framework for Approaching Any Design Problem

When asked to design a system, work through these steps in order:

1. Clarify requirements — functional (what the system does) and non-functional (how well it does it)
2. Estimate scale — how many users, requests/second, data size, read/write ratio
3. Define the API — what are the inputs and outputs?
4. Design the data model — what data do you store, and how?
5. Sketch high-level architecture — major components and how data flows between them
6. Deep dive on critical components — wherever the scale or complexity is highest
7. Address failure modes — what breaks, and what happens when it does?
8. Discuss tradeoffs — what did you give up, and was it worth it?

This track follows this framework throughout. Each article focuses on one architectural concept, but by the end you'll have enough vocabulary and intuition to apply the full framework.

What's Covered in This Track

Start with the next article: Scalability — the most fundamental dimension of system design.