System Design: a free course from zero to interview-ready

Think of it like this

Analogy

Think of a food truck that becomes a restaurant chain. One cook, one truck, one menu works for a street corner. As the line grows, you add a second cook, then a separate prep kitchen, then a host to seat people, then a central warehouse that supplies every location. Each change fixes a specific bottleneck: not enough hands, not enough space, too much waiting.

Nobody starts a food truck by building a warehouse. But a good owner knows which change comes next. System design is that skill for software.

The problem it solves

Code that works perfectly for ten users can fall over at ten thousand. The logic is the same; what breaks is everything around it:

One server runs out of CPU or memory, and pages slow to a crawl.
The database can't keep up with reads and writes.
A single machine fails at 3 a.m. and the whole product is offline, because it was a single point of failure.
Users far from your data center wait for every image to cross an ocean.

System design is how you predict these problems and choose the pieces (servers, databases, caches, queues, load balancers) that solve them, without building more than you need.

A real example

Example

A bakery’s website on launch day

A small bakery takes orders online. The site and its database run on one rented server, and for months that's plenty: a few hundred visitors a day.

Then a local TV segment mentions them. In one evening 20,000 people try to order. The server's CPU hits 100%, pages time out, and half-finished orders are lost. Nothing in the code was wrong; the design just never asked how many people, how fast, and what happens when the one machine struggles.

The fix follows the steps in this lesson: move the database to its own machine, put two app servers behind a load balancer, and cache the menu, which barely changes. Each change answers a question the first design skipped.

How it works

Every design starts with two questions:

What must it do? These are functional requirements: “users can post a photo”, “users can follow each other”.
How well must it do it? These are non-functional requirements: how many users, how fast (latency), how often it can be down (availability), how much it can cost.

Then you pick building blocks to meet them. Most systems are made of the same handful of parts, and this course covers each one. The best way to see how they fit is to grow a system step by step and watch which part each step adds.

Notice the pattern: each step fixes the bottleneck the last step exposed. That is most of system design. Find what will break next, pick the simplest piece that fixes it, and understand what that piece costs you.

Following one request

Once all those pieces exist, a single click travels through many of them. This is the path you'll learn piece by piece over the next lessons. Try it with and without a cache hit, and notice how much faster a request is when it never reaches the database.

The words you'll hear constantly

Scalability: does it keep working as load grows, ideally by adding machines rather than redesigning?
Availability: what share of the time it's up. 99.9% sounds high, but it still allows almost nine hours of downtime a year.
Latency and throughput: how long one request takes, and how many requests per second you can handle. Lesson 3 covers both.
Consistency: does everyone see the same data at the same time? Lesson 21 covers this.

There's no single right answer

Every choice trades something. A cache makes reads faster but can show slightly old data. More servers survive failures but cost more. Interviewers rarely look for one “correct” design; they want to hear you name the trade-off and pick deliberately.

Trade-offs

What you gain

Adding components at the right time lets a product grow from hundreds to millions of users.
Redundancy (more than one of everything) keeps the product up when parts fail.
Clear building blocks make a system easier to reason about and explain.

What it costs you

Every component adds cost, latency and another thing that can break.
Distributed systems have failure modes a single server never does: network splits, partial failures, stale copies.
More pieces mean more to monitor and more for new teammates to learn.

When not to use it

Don't add a component for scale you don't have yet. A single well-sized server and a managed database handle far more traffic than most new products ever see.
Don't split into many services just because large companies do. Start simple and split where it hurts.

In the cloud

Virtual machinesEvery major cloud sells this as a managed service, so you configure it rather than build it.

AWS1

Amazon EC2 (opens vendor docs)
Rent virtual servers by the second; you choose CPU, memory and operating system.

Azure1

Azure Virtual Machines (opens vendor docs)
Rent Windows or Linux virtual servers in Azure data centers.

Google Cloud1

Compute Engine (opens vendor docs)
Google's virtual machines, from tiny shared-core to very large memory machines.

How you’d set it up

A first production setup — one domain, one app server, one managed database.

Route 53
EC2 instance
Amazon RDS

Every stage in the playground above has a managed version in each cloud. You'll meet them lesson by lesson: load balancers in lesson 6, caches in lesson 14, CDNs in lesson 15, and so on.

Interview questions

Try answering out loud first, then open the model answer.

How would you scale a web app from one user to a million?

Model answer

I'd go step by step and only add what the current scale needs. Start with one server and a managed database. Move the database to its own machine so each can scale separately. Put a load balancer in front of several stateless app servers so we can add capacity and survive a server failure. Add a cache for hot reads, then a CDN for static files. Add database read replicas when reads outgrow the leader, and only then consider sharding or splitting into services. At each step I'd point to the metric that says it's needed, like database CPU or p99 latency.

What's the difference between functional and non-functional requirements? Give examples.

Model answer

Functional requirements say what the system does: “users can upload a video”, “users get a notification when someone comments”. Non-functional requirements say how well it must do it: “video starts playing within 2 seconds for 95% of users”, “99.95% availability”, “store 5 years of uploads”. In an interview I clarify both before drawing anything, because the non-functional numbers drive most of the design.

What is a single point of failure, and how do you remove one?

Model answer

It's any component whose failure takes the whole system down, like the only database or the only load balancer. You remove it with redundancy: run at least two, spread across failure zones, with a way to fail over automatically. For stateless servers that's just running more behind a load balancer. For stateful parts like databases it means replication plus a failover process.

Quiz

Pick an answer to see whether it’s right and why.

0 of 7 answered

Key terms

System design: Deciding which parts a software system needs, how they connect, and how data moves between them so it stays fast and reliable as it grows.
Server: A computer that waits for requests over a network and sends back responses.
Client: The program that sends a request, such as a browser or a mobile app.
Database: Software that stores data on disk in an organized way so it can be queried and survives restarts.
Scalability: How well a system keeps working as load grows, ideally by adding more resources rather than redesigning.
Availability: The share of time a system is up and answering correctly, often written as "nines" (99.9%).
Latency: How long one request takes from start to finish, usually measured in milliseconds.
Single point of failure: One component whose failure takes the whole system down.
Functional requirement: Something the system must do, such as "users can upload a photo".
Non-functional requirement: How well the system must do it, such as speed, uptime, cost or security targets.