I Learned System Scaling from a Kid Named Server

6 february 2026

I still remember my uncle and aunt who had only one child when I was eight. His name was Server. Server was polite, responsible, and always available. But he was constantly frustrated. He had to go to school, buy groceries, take care of his parents and sometimes all at the same time.

When both my uncle and aunt needed him simultaneously, Server would break down. My uncle wasn't a great system designer. My aunt was. During Valentine's week, they decided to add a junior Server. A few months later, Server welcomed a sister. Within three years, there were four siblings.

Suddenly, groceries, household chores, and taking care of parents became easy. The workload was distributed. No one was overwhelmed anymore. And that's ladies and gentlemen called Scaling.

When the number of requests on your platform starts increasing, you're left with three choices:

  1. Let the server break down and lose your users (just like you lost her).
  2. Upgrade the server's resources to make it a bigger machine that can handle more requests in less time (vertical scaling).
  3. Increase the number of servers to handle requests more efficiently (horizontal scaling).

Few techniques for better scalability:

Cloning (Horizontal Scaling)

Also known as horizontal scaling, this approach involves running multiple servers with the same configuration and codebase. Requests are distributed across these servers using a load balancer.

A load balancer acts as a layer between the client and the application servers. It monitors incoming requests and routes them to servers based on multiple factors such as server health, current workload, and availability.

It is essential that all servers run the same codebase so that deployments and upgrades can be managed centrally and rolled out to all servers simultaneously.

Databases

My first database was MySQL, everyone's first database was MySQL, right? It's simple, easy to implement, and life feels great at the beginning. But when an application starts getting more attention, the database often becomes a bottleneck.

You can apply techniques like denormalization, or hire a DBA (Database Administrator) to set up master-slave replication, but even then, serving users efficiently at scale becomes challenging.

Using a NoSQL database can help address some of these issues. NoSQL databases can provide faster lookups for certain access patterns, and scaling them horizontally is generally easier.

Caching

Caching is one of my favorite techniques. Caching means storing the most frequently requested data as key-value pairs in memory (RAM) to enable fast lookups and serve requests almost instantly. Redis and Memcached are popular tools commonly used for caching.

Caching acts as a layer between the application and the data storage. When a user makes a request, the application first checks the cache instead of directly querying the database. Most of the time, the required data is already available in the cache, allowing the server to respond much faster and significantly reducing database load.

Caching improves performance, but introduces complexity around cache invalidation which is one of the hardest problems in system design.

Asynchronism

As I mentioned earlier, my uncle wasn't a good system designer but my aunt was. Imagine my aunt needs money instantly for shopping, and when she asks my uncle, he says, "Wait! Let me go out and earn some." That would ruin her mood and the whole house wouldn't have food for at least two days (she wouldn't be very happy). You also don't want your users to get angry because of a slow response and eventually lose them.

That's where asynchronous systems come into play.

Instead of making users wait while long or blocking tasks are executed, asynchronism allows the server to perform time-consuming operations in the background. This way, when a user makes a request, the system can respond immediately or at least as quickly as possible while the heavy work continues under the hood.

This was my first technical blog, and I'd love to know if you found it useful. Until then, I'm going to rot in bed.


back to the blog / original on medium