What Is System Design? A Beginner's Guide

System design is deciding how the parts of a software system fit together so that it does its job, stays fast as it grows, and keeps working when things break.

Writing code solves one problem on one computer. System design answers bigger questions. How do you serve ten million users? What happens when a server dies? Where should the data live?

Why learn it?#

• Interviews: experienced developer roles often include a design round, and more fresher roles now ask the basics.
• Daily work: every feature involves choices about data, speed and failure.
• Understanding: you will see why products such as WhatsApp, YouTube and Swiggy are built as they are.

A simple system that grows#

Most systems begin small:

Users --> One server (app + database)

This works, until it does not. As users arrive, each limit you hit leads to a new part:

                       +--> App server --+--> Cache
Users --> CDN          |                 |
      --> Load balancer+--> App server --+--> Primary database --> Replicas
                       |                 |
                       +--> App server --+--> Queue --> Workers

Each box in this picture has a lesson in this course. None of it is magic: every part exists because of a specific problem.

Requirements come first#

A design is only good or bad relative to what it needs to do.

The non-functional requirements usually shape the design most:

Everything is a trade-off#

There is no perfect design. A cache makes reads faster, but data can be stale. Copies of data improve availability, but they may disagree. Good engineers name the trade-off, and choose based on the requirements.

If you remember one phrase from this course, make it this: it depends, and here is what it depends on.

How this course works#

1. Foundations: how to think, estimate and measure.
2. Building blocks: the standard parts, and when to use each.
3. Case studies: complete designs for the questions interviewers ask most.

Design is about ideas, so many lessons use diagrams. Where an idea can be shown in code, such as caching, rate limiting or consistent hashing, there is a small Python program, and the output shown is its real output. Numbers about real-world systems, such as traffic or latency, are rough estimates for reasoning with, not measurements of any company's system. The case studies are sensible designs for learning, and not descriptions of how those companies really work.

You should know some SQL and basic HTTP APIs first. Knowing Docker helps too.

Key takeaway#

Next: How to Answer a Design Question.