System Design Basics: Scaling Strategies

This is the very first article in our journey of learning and understanding system design. Don't worry — I won't take much of your time, and I'll keep everything as simple as possible. The structure of this blog will be:

Why? → What? → Case study → Advantages and disadvantages.

This structure will remain the same for all future articles.

WHY DOES SCALING EXIST?

Imagine you are running a SaaS. Initially, your infrastructure (let's say a server) can accommodate 1,000 users at once. People love your application and the number of users explodes, but your server can still only handle 1,000 users at a time, and the number of active users becomes 1,500. What happens? Your application crashes due to the heavy traffic it was not designed to handle. To accommodate more users and process more traffic, you have to upgrade your current system — a process that, in technical terms, is called scaling. The two most common types of scaling is 'vertical scaling' and 'Horizontal scaling'. And remember, we don't just scale up — sometimes we scale down when traffic is low to save costs.

What is vertical Scaling (Scaling Up) ?

Vertical Scaling means adding more power (CPU, RAM, GPU, or SSD) to an existing server. Think of it like upgrading your laptop from 8GB to 16GB of RAM or swapping an i5 for an i9.

Case Study: Early-stage Startup

A small startup launches a simple web app on a basic cloud instance. As they get their first 1,000 users, the server starts lagging. Instead of redesigning the whole system to work across multiple servers, the developer simply clicks "Resize Instance" in AWS or GCP to give it more RAM. This buys them time to focus on features rather than infrastructure.

Pros	Cons
Simplicity: No need to change code or handle distributed logic.	Upper Limit: There is a physical limit to how powerful a single machine can be.
Low Latency: Data stays on one machine; no network overhead between servers.	Single Point of Failure: If that one big machine goes down, the whole app is dead.
Cost-effective (Small scale): Often cheaper for very low traffic.	Hardware Costs: High-end "beast" servers become exponentially expensive.
	Downtime: Adding physical resources to the system requires shutting down the application for the duration of the upgrade.

What is Horizontal Scaling ( Scaling out)?

Once you hit the "ceiling" of vertical scaling, or if you need High Availability (no downtime), you must move to horizontal scaling. This is how giants like Google and Netflix operate.

What it is?

Horizontal Scaling means adding more machines to your pool of resources. Instead of one giant "super-server," you have a "cluster" of many smaller, identical servers. This often pairs with Auto-scaling, where the system automatically adds or removes servers based on live traffic.

Case Study: E-commerce "Flash Sale"

An e-commerce site normally runs on 3 servers. During a "Big Billion Day" sale, traffic spikes 100x. An Auto-scaling group detects the CPU usage hitting 80% and automatically spins up 50 more identical servers to handle the load. Once the sale ends, it kills those extra servers to save money.

Pros and Cons

Pros	Cons
Infinite Scalability: You can theoretically keep adding servers forever.	Complexity: Requires a Load Balancer and "Stateless" application design.
Resilience: If one server crashes, 99 others are still running.	Network Latency: Servers may need to talk to each other over the network.
Cost-efficient (Large scale): You only pay for what you use via Auto-scaling.	Data Consistency: Harder to keep data synchronized across 100 machines.

SUMMARY

In this article we just learned about two basic terms in system designing 'vertical and Horizontal scaling'. In vertical scaling we upgrade one machine where as in horizontal scaling we just buy or rent out a new one when needed.

This was a fun and quick article on scaling. I hope you enjoyed it and learned something new. Let's meet again in the next article to explore a different topic in system design.