Skip to content

System Design Basics

This is the first note in a series about System Design. We will explain everything in simple words, without heavy jargon, so that anyone (even beginners) can understand it.

A server is nothing fancy. It is just a computer/machine that runs all the time (24/7) and has a public address (IP address) so that anyone on the internet can reach it.

  • Does a server have to be “in the cloud”? No! Even your own laptop can act like a server, if you keep it turned on all the time and give it a public IP address. But normally we don’t do this because:
    • We don’t want to keep our personal laptop on 24/7.
    • We don’t want to expose our personal machine to the whole internet.

That is why companies like AWS, Google Cloud (GCP), DigitalOcean exist. They give you a virtual machine that runs all the time and has a public IP.

An IP address is like a home address for a computer. Just like your home has:

  • A street name and number
  • A city
  • A postal code
  • A state
  • A country

…a computer on the internet has an IP address (something like 10.2.3.4) so other computers can find it.

Problem: IP addresses are very hard to remember. Do you remember your friend’s phone number by heart? Probably not. So instead of typing 10.2.3.4, we want to type something easy like amazon.com.

DNS (Domain Name System) solves this problem. Think of DNS as a big global phone book (directory). It stores pairs like:

  • amazon.com10.2.3.4
  • google.com10.5.6.7

When you type amazon.com in your browser, your very first request actually goes to a DNS server asking “what is the IP address of amazon.com?” The DNS server replies with the correct IP, and now your browser can talk to the correct server.

This whole process is called DNS Resolution.

flowchart LR A[User types amazon.com] --> B[DNS Server] B -->|Returns IP address| A A --> C[Connects to Server using IP]

A server is a physical machine — it has some CPU (processing power) and some RAM (memory). Let’s say it has 2 CPUs and 4GB RAM.

Over time, as more and more users come to your website, the load (number of requests) increases. If your server does not have enough CPU/RAM, it becomes overwhelmed and can crash.

This is exactly why you sometimes see websites crash when everyone visits at once — for example, when exam results come out and everyone tries to check their result at the same time.

So, how do we fix this? There are two main ways to “scale” (grow) a system: Vertical Scaling and Horizontal Scaling.

Vertical scaling means: add more power to the same machine.

Example: Instead of 2 CPU + 4GB RAM, you upgrade the same server to 64 CPU + 128GB RAM.

flowchart LR A["Server: 2 CPU, 4GB RAM"] -->|Upgrade| B["Same Server: 64 CPU, 128GB RAM"]

Problems with Vertical Scaling:

  1. Waste of money - If your traffic is high only sometimes (like during a sale), you are paying for huge resources even when nobody is using your website 90% of the time.
  2. There’s always a limit - No matter how much you upgrade, at some point it will not be enough for really huge traffic.
  3. Downtime - You cannot add more CPU/RAM to a machine while it is running. You have to restart the machine. This means your website goes offline for a bit. For a big company like Amazon, even 1 minute of downtime during a big sale is unacceptable.

Horizontal scaling means: don’t upgrade one server — instead, add more servers (copies/replicas) that all do the same job.

flowchart LR A[Traffic Increases] --> B[Server 1] A --> C[Server 2] A --> D[Server 3 - newly added]

This way, when traffic increases, you simply spin up a new server alongside the existing ones. The old servers keep working while the new one boots up, so there is no downtime.

The New Problem: Which Server Gets the Traffic?

Section titled “The New Problem: Which Server Gets the Traffic?”

If you now have 3 different servers, each with their own IP address, but DNS can only point to one IP… how do you split traffic between all 3 servers?

This is where a Load Balancer comes in.

A Load Balancer is basically another server that sits in front of all your other servers. Its only job is to split (distribute) incoming traffic between all the available servers.

  • The DNS now points to the Load Balancer’s IP address (not the actual servers).
  • Every request first arrives at the Load Balancer.
  • The Load Balancer decides which server should handle each request.
flowchart LR U[User] --> DNS[DNS Server] DNS -->|Returns Load Balancer IP| U U --> LB[Load Balancer] LB --> S1[Server 1] LB --> S2[Server 2] LB --> S3[Server 3]

Popular tool name: On AWS, this is called ELB (Elastic Load Balancer). On GCP, it’s called Cloud Load Balancing. But the generic term is just “Load Balancer.”

How Does a Load Balancer Decide Where to Send Traffic?

Section titled “How Does a Load Balancer Decide Where to Send Traffic?”

There are different algorithms (strategies). The simplest one is called Round Robin:

  • 1st request → Server 1
  • 2nd request → Server 2
  • 3rd request → Server 3
  • 4th request → back to Server 1
  • …and so on.

This way, the load gets spread evenly across all servers.

How Does the Load Balancer Know a New Server Is Ready?

Section titled “How Does the Load Balancer Know a New Server Is Ready?”

When a new server is added (during scaling out):

  1. The new server needs some time to “boot up” (start).
  2. Once it’s up, it registers itself with the Load Balancer.
  3. The Load Balancer checks if the server is healthy — meaning, has it been running fine for at least a minute or so?
  4. Only after it’s confirmed healthy does the Load Balancer start sending traffic to it.

In the next note, we’ll look at how big companies like Netflix, YouTube, and Hotstar actually plan for traffic, and why one company’s system design does not work for another company.