When I first heard the words "system design", I thought they meant drawing diagrams. You know the kind: a client, an arrow to a server, an arrow to a database.
Then a few more boxes and a few more arrows, maybe Redis, Kafka and S3, until the page is full. And somehow, the more boxes you had, the better the design seemed to look.
But that isn't really system design. The boxes are only a way of showing a design. The design itself is the set of choices you make about how your software should work.
Imagine we're building a food delivery app like Swiggy or Zomato. Before drawing anything, we have to answer some simple questions:
- Where do we store the restaurants, menus and orders?
- How does a new order reach the restaurant?
- What happens if the restaurant doesn't respond?
- What happens when the whole city orders dinner at 8pm?
- How do you know where your food is?
Now try it yourself.
Your turn
Pick an app you used today. Before drawing anything, write the questions you'd need to answer.
- 01
- 02
- 03
Stuck? Think about where the data lives, what happens when something fails, and what happens when it gets busy.
Those questions, and the decisions you make to answer them, are the system design. The diagram comes later, and its only job is to help us see those decisions and explain them to others.
So, put as simply as possible:
System design is deciding how the different parts of a software system should work together.
That's all it is. You don't need to know distributed systems, Kubernetes, Kafka or any other complicated technology to understand the idea. Whenever you build software and find yourself asking what the system should look like, and how its parts should work together, you are already doing system design.
So what makes a design good? Not the number of boxes, and not how famous the tools are. A good design solves the business problem: people can order food, restaurants get their orders, and the money arrives. And it does that within the limits you actually have: how many users you will have, how much budget you have for this system, how big your team is, and how soon you need to ship.
A good design solves the business problem, within the limits you have.
That means one server and one database, chosen for the right reasons, is a real system design. Often, it's the best one. Adding parts you don't need yet doesn't make a design better. It makes it more expensive, slower to build, and easier to break. That's called overengineering.
We will design the system for this food delivery app through the rest of the course. We'll start it as one small server, and grow it step by step into something a whole country can order from.