Vol. 1 System Design Basics: Scaling from Zero to Millions
Laying the foundation every scalable system is built on
Introduction
The topics and theories of our favorite subject, system design, are inspired by the famous book "System Design Interview" by Alex Xu. This article aims to build the foundation of system design, covering basic concepts that will be used as we progress to designing systems that can handle users from zero to millions.
And since I’m a big My Hero Academia fan (guilty as charged!), you might notice a quote or two sneaking in along the way. As All Might says: “Go beyond! Plus Ultra!”
Why Basics Matter
These concepts are the foundation of every system design journey. Whether you’re building something simple like a rate limiter or designing a full-fledged application like Instagram, the same building blocks apply. It might be too soon to dive into Instagram-level systems but don’t worry, we’ll definitely get there.
As Midoriya once said:
“There was a time in my life when I would’ve given up, but I kept pushing forward.”
That’s exactly how learning system design feels challenging at first, but step by step, you’ll go beyond.
Core Concepts of System Design
Let's dive into the main part of the blog.
1. Single Server Setup
The adventure of computing and services begins with a single server, a user, and the all-knowing DNS server.
A user types in a domain name. The DNS translates this human-friendly name into the IP address of the server, and suddenly the user knows where to find it. It’s like the user only knows the nickname of the server, but the DNS knows its home address. And if you want to gossip with the server, you need to go knock at its door that’s the IP address.
In this setup, everything the application code, the database, and the storage lives on one machine.
Think of a single hero (like Midoriya in his early days) fighting all the villains alone. He can protect a small area, but if too many villains show up at once, he gets overwhelmed.
One server = one hero doing everything.
2. Database
As more users join, a single server can’t handle everything both running the app and storing all the data. So, we bring in a database whose main job is to store and organize information. The server just asks the database whenever it needs to save or read something.
A hero might have amazing memory storing all the details about villains, battles, and strategies. But when the workload gets heavier, the hero writes everything down in a Hero Logbook (like All Might passing down his notebook to Midoriya).
The database = the hero’s logbook where all important info is stored.
There are mainly two kinds of databases:
Relational Databases (SQL)
Think of it like spreadsheets with rows and columns.
You can connect different tables (like a table of users and a table of orders).
Very organized, great when your data has a clear structure.
Examples: MySQL, PostgreSQL.
Non-Relational Databases (NoSQL)
Instead of tables, they store data more freely, often like JSON files.
Flexible, good for apps where the data shape changes a lot.
Easy to grow across many servers when traffic is huge.
Examples: MongoDB, DynamoDB.
In short:
Use SQL when your data is neat and well-organized.
Use NoSQL when your data is messy, flexible, or growing super fast.
3. Vertical Scaling VS Horizontal Scaling
Think about your own device — a laptop, PC, or even your smartphone. If it starts running slow because the CPU, RAM, or storage isn’t enough, you have two choices:
Vertical Scaling (Scale Up)
This is like upgrading your device with better parts.
Add more RAM, replace the CPU with a faster one, or upgrade to a bigger SSD.
In servers, vertical scaling means giving a single machine more power.
Simple to do.
But there’s a limit you can’t keep upgrading forever, and it gets expensive.
Horizontal Scaling (Scale Out)
Instead of buying one super-powerful laptop, imagine having multiple laptops working together.
Each laptop handles part of the workload, and together they can do much more.
In servers, this means adding more machines and distributing the traffic among them.
Much higher capacity, no single point of failure.
More complex to manage because you need load balancers and coordination.
In short:
Vertical scaling = making one server stronger.
Horizontal scaling = adding more servers to share the work.
Vertical Scaling: Midoriya unlocking 100% of One For All to become way stronger. One hero, but much more powerful.
Horizontal Scaling: Instead of just Midoriya fighting, the entire Class 1-A joins in. Each hero handles part of the battle, and together they defeat the villains.
Vertical \= powering up one hero. Horizontal = teaming up multiple heroes.
4. Load Balancer
Imagine this: your device is so popular that many people want to use it at the same time. But one device can’t handle everyone at once. So, instead of forcing them to fight over it, you give each person a different device to use.
That’s what a load balancer does in system design.
Think of Eraser Head (Aizawa) during training. When the students face too many combat exercises, he splits the class into groups and assigns each villain fight to the right student based on their quirk.
Load balancer = the teacher who distributes the workload to the right heroes.
Here’s how it works step by step:
The user types in the website name.
DNS gives back the IP address of the load balancer (not the server directly).
The user sends the request to the load balancer.
The load balancer then decides which server should handle that request.
The load balancer makes sure that:
No single server is overloaded.
New servers can be added when traffic is high.
Extra servers can be removed when traffic is low (saving costs).
In short:
A load balancer is like a traffic manager it takes all incoming requests and spreads them evenly across available servers so that the system stays fast and reliable.
5. Database Replication
Imagine you save important files on your laptop, but the hard drive crashes. If you had made a backup copy on an external drive, you’d still be safe.
That’s exactly the idea behind database replication in system design — making copies of your database so your system doesn’t break if one fails.
Here’s how it usually works:
Master–Slave Setup
Master Database: Handles all the write operations (adding, updating, or deleting data).
Slave Databases: Receive copies of the master’s data and handle the read operations.
If the master fails, one of the slaves can be promoted to act as the new master.
Why it’s useful
Increases reliability, even if one database crashes, you don’t lose everything.
Improves performance, reads can be spread across many slaves, avoiding overload on a single database.
Helps with scaling as the system grows.
One trade-off: sometimes the slave might not have the very latest data at the exact moment of failure (called replication lag), but it’s usually close enough and can be fixed once the system recovers.
In short:
Database replication = having multiple copies of your database so your system stays safe, fast, and available
6. Cache
Imagine every time you open your laptop or phone, it has to load something important (like your wallpaper or your most-used app) from the hard drive (HDD). Hard drives are slower, so this would take time.
But if the device keeps that data in a cache (a small, super-fast memory), it can load it instantly.
In system design, a cache works the same way:
It stores frequently accessed data in a faster storage layer (like in-memory).
So instead of going all the way to the database every time, the server can quickly fetch the data from the cache.
Benefits of caching
Speed: Faster responses for users.
Reduced load: Fewer trips to the database.
Cost saving: Less strain on expensive resources.
Example:
Think of logging into Instagram. Your profile picture, username, and bio don’t change every second. So instead of fetching them from the database every single time, Instagram puts them in a cache so they load instantly when you open the app.
In short:
Cache = a shortcut to the data you need most often. It makes systems faster and smoother.
How These Fit Together
All the pieces we’ve covered servers, databases, scaling, load balancers, replication, and caching work like parts of a small city:
Server = the office where work happens
Database = the record room
Scaling = making the office bigger or opening more branches
Load balancer = the receptionist guiding visitors
Replication = backup record rooms
Cache = quick-access drawer with popular files
Together, they form a basic but reliable system that can handle more users, stay available, and run faster.
Conclusion
We’ve taken the first big step into system design, from a single server all the way to caching and replication. These building blocks form the foundation of any scalable system and will keep showing up no matter what you design.
But this is just the beginning. In the next blog, we’ll go beyond the basics and explore more advanced topics like CDNs, stateless web tiers, data centers, message queues, and what it really takes to scale to millions of users. Stay tuned things are about to get even more exciting! 🚀
As All Might says: “When there’s nothing to be gained, rising to the challenge at those times… is surely the mark of a true hero.” 🌟
