Start Here: What System Design Is and How to Learn It

Most people meet system design through a diagram. Someone shows a picture with a load balancer, three servers, a cache, a database, a queue and a CDN, and says "this is how a real system looks". The learner memorises the picture. Then an interviewer asks them to design a parking-ticket system or a notification service, and the memorised picture does not fit. They add a cache because diagrams have caches, and a queue because diagrams have queues, and cannot explain why either is there.

This course takes the opposite route. You will learn why each part exists, starting from one server, and add parts only when a real problem demands them. By the end you will be able to design systems you have never seen before, estimate how big they need to be, and explain what happens when pieces fail. That is what interviews and real jobs actually ask.

• What "system design" means, and how high-level design differs from low-level design.
• Why companies ask system-design questions, and what they are really checking.
• How a simple app grows from one server into a distributed system, one problem at a time.
• The common components (DNS, CDN, load balancer, application servers, cache, database, queue, workers, object storage, search) and the problem each solves.
• The seven-phase method used in every article and case study of this course.
• What changes between SDE-1 and SDE-2 expectations.
• How to study this course so it sticks.

System design is the work of deciding which components a software system needs, how they connect, how data moves between them, and how the whole thing behaves under load and under failure, so that it meets its requirements.

Requirements are the anchor. "Design a photo-sharing app" is not a design problem yet. "Let 2 million people a day upload photos and see their friends' photos within a second, without losing any photo" is. The second sentence gives you something to design for.

There are two common levels of design:

When an interviewer says "system design round" without qualification, they almost always mean HLD.

An API server can be written in Java, Go, Python, Node.js, C# or Rust. A load balancer does not care. A cache does not care. The design decisions in this course (where to cache, how to split data, what to do when a call times out) are the same whatever language the services are written in.

This course uses Java for a few small runnable programs, because the wider learning path on this site uses Java. Those programs model an idea, such as how a token bucket refills or how consistent hashing moves keys. They are never the point. If you work in another language, read the Java as pseudocode.

Here is the honest version, without hype.

• It shows how you think about trade-offs. Most real engineering decisions have no single right answer. Caching makes reads faster but data can go stale. Splitting a database across machines adds capacity but makes some queries harder. Interviewers want to hear you weigh both sides.
• It shows whether you ask before you build. Strong candidates clarify requirements before drawing anything. Weak ones draw a diagram from memory.
• It shows whether you think about failure. Real systems lose machines, networks drop packets and dependencies slow down. A design that only works on the happy path is not a design.
• It shows how you communicate. You must explain a structure out loud, keep the interviewer with you, and change course when they push back.

What it is not: a test of how many technology names you know. Saying "Kafka, Redis, Kubernetes, microservices" in the first two minutes is a common way to lose points, because it signals pattern-matching instead of reasoning.

The best way to understand the components is to watch a system need them. Let us follow a hypothetical photo-sharing app called Pixly as it grows. The numbers are illustrative.

On day one, Pixly runs on a single server. The web application, the database and the uploaded photos all live on the same machine.

  Browser / mobile app          |          v  +----------------------------+  | One server                 |  |  - application code        |  |  - database                |  |  - photo files on disk     |  +----------------------------+

This is a perfectly good design for a few hundred users. It is cheap and simple, and there is only one thing to fix when something breaks. Starting here is not naive. Staying here after it stops working is.

Pixly grows. The database and the application compete for the same CPU and memory, and a heavy query slows down every page. We move the database to its own server. Now each can be sized for its own work.

  Clients     |     v  App server  ---->  Database server

Problem solved: resource contention between two kinds of work.

At peak hours, one application server cannot handle all the requests. We could buy a bigger machine (vertical scaling), but there is a limit and a bigger machine is still one machine that can fail. Instead we run several identical application servers (horizontal scaling) and put a load balancer in front to spread requests between them.

  Clients     |     v  Load balancer     |------------|------------|     v            v            v  App 1        App 2        App 3     \            |            /      \-----------+-----------/                  v              Database

Problem solved: more request capacity, and no single application server whose failure takes the site down. This only works if any server can handle any request, which is why the servers are kept stateless. Article 08 explains this.

Most requests read the same popular data again and again: profile pages, photo captions, like counts. The database does the same work repeatedly. We add a cache, an in-memory store that keeps copies of frequently read data so most reads never reach the database.

Problem solved: database read load and read latency. New problem created: the cache can hold stale data. Article 09 is about managing that.

Photo files fill the disks of the application servers, and every server needs access to every photo. We move photos to object storage, a service built to store huge numbers of files durably, and serve them through a CDN (content delivery network), a set of servers around the world that keep copies close to users.

Problem solved: file storage that does not depend on any one server, and fast downloads for users far from our data centre.

When a user uploads a photo, Pixly also creates thumbnails, scans the image and notifies followers. Doing all that before replying makes uploads slow, and if the notification step fails the whole upload fails. We put a message queue between the upload and the follow-up work. The upload request saves the photo, puts a message on the queue and returns. Workers take messages from the queue and do the slow work in the background.

Problem solved: fast responses, and failures in follow-up work no longer break the main request.

Look at what happened. We never added a component because "real systems have one". Each time, a specific problem appeared (contention, request volume, repeated reads, large files, slow follow-up work), and we added the smallest thing that solved it. Each addition also brought a new cost or risk that we now have to manage.

That is the whole discipline in miniature:

1. Start with the simplest design that meets the requirements.
2. Ask "What breaks first?" as load grows.
3. Fix that bottleneck, and only that one.
4. Ask "What happens when this new part fails?"
5. Repeat.

Here is the mental model you will use throughout the course. It shows the components a request may pass through, in the order it usually meets them.

  CLIENT (browser, mobile app, another service)     |     v  DNS                    turns a name into an address     |     v  CDN / EDGE             serves cached static content near the user     |     v  LOAD BALANCER          spreads requests across healthy servers     |     v  API / APPLICATION      runs the business logic  SERVERS     |            \     v             \--> CACHE            fast copies of hot data  DATABASE              (checked before the database)     |     v  MESSAGE QUEUE /        hands work to be done later  STREAM     |     v  ASYNC WORKERS          do slow or background work     |     v  OBJECT STORAGE /       files; full-text search; other services  SEARCH / OTHER

Cloud providers sell managed versions of most components. They are useful as concrete examples, but they are not the thing to learn. Learn the problem and the concept; the product names follow. The names below are examples as of October 2026, and providers rename and merge products regularly.

If you can say "we need a durable queue so uploads return quickly and failed thumbnail jobs are retried; on AWS that might be SQS, or we could run RabbitMQ", you have shown the concept first and the product second. That is the order interviewers want.

Keep these three questions in your head for the whole course. They are more useful than any diagram.

1. Why is this component here? Name the problem it solves. If you cannot, remove it.
2. What breaks first? As traffic or data grows, which part reaches its limit first: CPU on the app servers, database writes, database reads, network bandwidth, disk space?
3. What happens when this fails? If this server, cache, queue or network link disappears for five minutes, what do users see, and what data could be lost or duplicated?

You will see these questions in every article. By the end they should feel automatic.

Every design in this course, from a URL shortener to a ride-hailing platform, follows the same seven phases. Article 29 expands them into a 21-item interview checklist, but the phases are enough to start.

Notice that architecture appears only in phase 5. Phases 1 to 4 decide what the architecture must do. Skipping them is the most common beginner mistake.

Interview expectations vary by company, so treat this as a general guide rather than a rulebook.

This course is built to serve both. Articles 01 to 13 and the first three case studies are the SDE-1 core. Articles 14 to 28 and the later case studies add SDE-2 depth. Each article tells you its level.

Read in order. Each article builds on the ones before it. Capacity estimation comes before the building blocks on purpose: you need numbers to know whether a component is necessary.

Reading about architecture is not the same as being able to produce one. Use this routine:

1. Read once for the idea. Aim to explain it to a friend in two sentences.
2. Redraw the diagrams from memory. On paper, without looking. Then compare.
3. Redo the numbers yourself. Estimation is a skill of the hands, like arithmetic.
4. Say it out loud. Explain the design as if to an interviewer. You will find the gaps quickly.
5. Do the exercises before opening the solutions. Struggle for 15 to 20 minutes first.
6. Revise. Come back after a day, a week and a month. Article 45 has a schedule.

• Starting with technology names. "We'll use Kafka" before anyone knows whether there is anything asynchronous to do.
• Skipping requirements. Designing for "scale" without knowing whether that means a thousand users or a hundred million.
• Drawing the final architecture first. Interviewers want to see how you get there.
• Ignoring numbers. Without estimates you cannot tell whether one database is enough.
• Only the happy path. Not asking what happens when the cache, the database or a network link fails.
• Treating one design as "correct". Most questions have several good answers with different trade-offs. Say which one you chose and why.
• Memorising company architectures. Published descriptions of famous systems are interesting, but they solve those companies' problems, at their scale, with their history.

Copy this into your notes. "Done" means you read the article, redrew its diagrams from memory and attempted every exercise.

• 01. Start Here: What System Design Is and How to Learn It
• 02. Functional and Non-Functional Requirements
• 03. How a Web Request Travels
• 04. API Design
• 05. Synchronous vs Asynchronous Communication
• 06. Back-of-the-Envelope Estimation
• 07. Estimating Storage, Bandwidth, Cache Size and Server Count
• 08. Load Balancers
• 09. Caching
• 10. CDNs and Object Storage
• 11. Message Queues, Pub/Sub and Event Streams
• 12. Relational Databases and Data Modeling
• 13. Database Indexes
• 14. Transactions and Concurrency Control
• 15. Database Replication
• 16. Sharding and Partitioning
• 17. SQL vs NoSQL
• 18. Why Distributed Systems Are Hard
• 19. CAP Theorem and Consistency Models
• 20. Idempotency, Retries and Delivery Guarantees
• 21. Distributed Transactions
• 22. Distributed Locks and Leader Election
• 23. Fault Tolerance
• 24. High Availability and Disaster Recovery
• 25. Observability
• 26. Monolith vs Microservices
• 27. Event-Driven Architecture, CQRS and Event Sourcing
• 28. Security in System Design
• 29. The System Design Interview Framework
• 30. Design a URL Shortener (and Pastebin)
• 31. Design a Rate Limiter
• 32. Design a Distributed Cache
• 33. Design a Notification System
• 34. Design a Chat System
• 35. Design a News Feed
• 36. Design Search Autocomplete
• 37. Design a Job Scheduler
• 38. Design a Ticket Booking System
• 39. Design a Payment System
• 40. Design a Video Streaming Platform
• 41. Design a Ride-Hailing System
• 42. Design a Food Delivery Platform
• 43. Design an E-Commerce System
• 44. Design a Web Search Engine
• 45. Practice Plan and Job-Ready Checklist

Users -> CDN -> Load balancer -> 6 app servers -> Redis cache -> PostgreSQL                                     |                                     v                                   Kafka -> 3 worker services

• Next: Functional and Non-Functional Requirements: Latency, Throughput, Availability and Scale turns "design a photo app" into something you can design for.
• If the web itself is new to you, How a Website Works: From Typing a URL to Seeing the Page is a gentle introduction, and What Is an API? A Plain-English Explanation With Real Examples explains APIs from zero.
• For the cloud vocabulary, Cloud Computing in Plain English: What It Is and Why Everyone Uses It explains what "managed service" and "region" mean.