System Design Basics for Dummies

6 min readMay 17, 2024

What is System Design and why do we even need it?

Have you ever seen a building being constructed without any planning or an architect? Of course not, right? The same goes for designing software. The entire design process happens before the actual implementation.
Just like an architect decides how to lay the foundation, which materials to use, and how the rooms will be arranged, software engineers determine how many servers will be needed, which databases to use, and more.
That’s why system design is so important, and excelling in it is a hallmark of a great engineer. So, as we delve deeper into the tech world, remember, great systems start with great designs.

Let’s start with a simple question. When you type google.com into your laptop or mobile browser, do you think it directly connects to Google’s server? If you said yes, sorry, but that’s not correct. To understand why, you need to grasp a small concept called DNS.
But first, let’s understand what an IP address is. Just like we have names in different languages like English, Spanish, Hindi, etc., computers have names too, but they are in numbers. This numeric name is called an IP address, which looks something like this: 192.12.87.13, four numbers separated by dots. Every computer or server on the internet is known by this IP address.
Now that we understand IP addresses, let’s move on to DNS. So, when you type google.com in your browser, how does it know where Google’s server is located and how to connect to it? And if tomorrow you ask it where sweetcodey.com is, how will it know? Is it maintaining a map that google.com is at 192.12.87.13 and sweetcodey.com at 192.33.44.1? With infinite websites in the world, can your browser keep track of them all? No!
That’s where DNS comes in. Your browser always connects to a DNS server, and this server has a mapping of websites to IP addresses. Your browser goes to it and asks, ‘Tell me where sweetcodey.com is,’ and it gives the IP address. Now your browser can connect to sweetcodey.com using its IP address.

So, next time you try to connect to a website, remember this whole process.

Let’s dive into two crucial concepts that are the heart of the entire system design process: Horizontal and Vertical Scaling.
Imagine your website is hosted on a single server. You have 100 loyal users who use your website. But in a month, 2,000 users start using your website, and it can’t handle the load — it becomes very slow. So, you increase the size of your server, meaning its RAM, computing power, etc. Now your website becomes stable again and can easily handle the load of 2,000 users.
Six months later, your business grows even more, and now 10,000 users are visiting your website, so you increase the server size again. This upgrading of server capabilities based on load is what we call Vertical scaling.
Now imagine that a year later, your website starts getting 20,000 users. You try to increase the server size again, but it’s no longer possible. There’s a limit to how much you can expand a server, and you’ve reached that limit. So, what do you do next? You try another approach.
Instead of one, you set up two servers and divert some users to the first server and the rest to the second server. This way, you can comfortably handle the load of 20,000 users. This approach, where you increase the number of servers rather than their size, is known as Horizontal scaling.

A general approach people usually take is to start with vertical scaling and then, when it becomes too expensive, they switch to horizontal scaling.

Load balancer is a concept that’s widely used today and has become a buzzword in system design interviews. But really, it’s a simple and intuitive concept.
We know that during horizontal scaling, we distribute incoming traffic across our servers. But how does this happen? That’s where the Load balancer comes in.
It balances the load, i.e., distributes the incoming load across multiple servers. So, whenever someone visits your website, the load balancer routes that person to one of the servers.
For example, let’s say person1 gets routed to server1, and person2 gets routed to server2. But wait! What’s the logic behind which person goes to which server? Well, this logic can vary according to your needs — maybe it’s based on location, or perhaps on the IP address, etc.

Imagine you’ve created a large website and hosted it on multiple servers. You also have a load balancer distributing incoming traffic across these servers. But you notice that even this setup isn’t enough to manage your user traffic effectively.
You think about adding one or two more servers, but this approach is becoming very expensive. You observe that most of the time, your servers are just busy managing data — reading and writing data. This is where databases come into play.
A Database is a special place that specializes in managing data. Reading or writing data from or to a database is much faster compared to application servers because they are built specifically for this purpose.
Think of a database in simple terms as a computer or server that specializes in handling data.

So, now we understand why databases are needed, right?

Let’s say the number of users for your website grows from 100 to 20,000 in just one year. Naturally, your database size keeps increasing. It’s very likely that it won’t be able to handle data effectively for 20,000 users — it will slow down. So, what do we do?
The solution is simple, similar to what we did with application servers: set up multiple databases with different data on them and distribute the incoming load among them. This technique is called database sharding — a very simple but powerful concept.
Now, the next question arises: on what basis should we shard? Well, that depends on your needs. For example, you could shard based on location. Let’s say Database 1 holds all the data for the US-West, Database 2 for the UK, and so on. Or, the division of data could be based on some other criteria too.

We all know that sharding involves dividing our database’s data across multiple databases. So, part 1 of the data will be in DB1, part 2 in DB2, and so on. But what happens if one of these databases crashes? All the data on that database would be lost forever, which would be a terrible situation.
To solve this problem, we use DB Replication. As the name suggests, we just create replicas of our databases. Now, even if one or two databases crash, we have other replicas that we can use.
However, there’s a problem with this approach too. How do we maintain the same data across all our databases? For instance, if DB1 is updated with data1, how do the other databases get updated?
This is where the Master-Slave architecture comes into play. Also, it’s generally observed that the DB Read to Write ratio is 100:1. So, why not optimize our DB system for this style? In Master-Slave architecture, we have one Master where only writes occur, and several Slave databases where reads are performed.
When someone wants to read from the database, they simply read from one of these read replicas, and if they need to write, they write to the Master.
But one thing to keep in mind is that when we write to the Master DB, we need to ensure that all updates are also made in the Slave DBs, otherwise our read replicas will end up with outdated data.