System design is the work of deciding how the pieces of a software system fit together: which servers handle requests, where data lives, how parts talk to each other, and what happens when something breaks. Writing a function is about getting one piece right. System design is about making many pieces work together for lots of users, all day, every day. It is also a standard part of software engineering interviews, so learning it early pays off twice.
A blueprint for software#
You wouldn't build a house by nailing boards together at random. You'd start with a blueprint that shows where the kitchen goes, how the plumbing connects, and which walls hold up the roof.
A system design is that blueprint for an application. When a service like Netflix or Instagram serves millions of people, the team has to plan:
- How data flows through the system
- Where each kind of data is stored
- How to handle a huge number of requests per second
- What happens when parts fail (they will)
- How to keep everything fast and available
Cooking dinner for yourself takes one pan. Running a restaurant that serves 500 people a night takes several cooks, specialised equipment, backup plans and coordination. That gap is the gap between a simple program and a designed system.
The core question is: how do you build software that keeps working under real-world demand, with many users, lots of data, and no downtime?
The four problems system design solves#
Almost every system has to deal with four problems. A restaurant makes a handy comparison for each one.
| Problem | Restaurant version | Software version | Tools you will learn |
|---|---|---|---|
| Scale | 5,000 guests arrive at once and one kitchen can't cope | Your app goes viral and jumps from 100 users to 10 million | Horizontal scaling, load balancers, sharding |
| Storage | Fridges, freezers and dry shelves suit different food | Profiles, photos, messages and payments each need different storage | Relational and NoSQL databases, blob storage, search indexes |
| Speed | Guests leave if food takes too long | Users leave slow pages and apps | Caching, indexing, CDNs, regional deployment |
| Reliability | The oven breaks during the dinner rush | A server crashes halfway through a payment | Replication, redundancy, retries, transactions |
Most design decisions trade one of these against another. A cache makes reads fast but can serve stale data. Replicating data across regions improves reliability but makes consistency harder. Learning system design is mostly learning these trade-offs.
What a typical system looks like#
Almost every web-scale system is built from the same handful of building blocks. You will meet each one in this course.
- Client – a browser or mobile app sends a request.
- DNS and CDN – DNS turns the domain name into an IP address. A CDN serves static files (images, scripts) from a server near the user.
- Load balancer – spreads requests across many identical app servers.
- App servers – run your business logic. They are kept stateless so you can add or remove them freely.
- Cache – keeps hot data in memory so most reads skip the database.
- Database – the source of truth for structured data.
- Blob storage – holds large files such as videos and photos.
- Queue and workers – slow or bursty work (sending emails, encoding video) goes on a queue and is processed in the background.
Try it: a banking app#
Which of the four problems matters most for a banking app, and why? Think about it before reading on.
Two stand out:
- Storage (correctness): every transaction must be recorded permanently, balances must be exactly right, years of history must be kept, and regulators require proper retention.
- Reliability: if the system is down, people can't reach their money. A crash during a transfer must never lose funds, and data corruption destroys trust.
Speed and scale still matter, but a bank would rather be a little slow than ever be wrong. A social media feed makes the opposite choice: showing a slightly stale post is fine if the page loads instantly. Asking "what must never go wrong here?" is a good first step in any design.
Where to go next#
- Networking fundamentals: how a request actually travels from client to server.
- Core databases: relational, NoSQL, blob and search storage.
- Caching: making reads fast.
- Queues: smoothing out bursty work.
Key takeaways#
- System design decides how servers, storage and communication fit together so software works for many users at once.
- It tackles four problems: scale, storage, speed and reliability.
- Most systems reuse the same building blocks: load balancers, stateless app servers, caches, databases, blob storage and queues.
- Every choice is a trade-off. Start by asking what the system must never get wrong.