When your app is just starting out, scaling isn’t something you think about much , and one decent server usually does the job. But as traffic grows, you eventually hit a wall and have to decide: do you make your server stronger or add more servers to share the load? Let’s break down these two approaches.
Scalability
When we first launch an app, the traffic is usually pretty manageable.
But as it becomes more popular, we might start getting way more requests than our current setup can handle.
The ability to deal with this increased number of requests is known as scalability.
We are essentially handling more requests by throwing “more money” at the problem.
There are two common approaches to this:
Vertical Scaling → Buy a bigger machine.
Horizontal Scaling → Buy more machines of the same capability.
Horizontal Scaling
Pros
- Better fault tolerance. If one machine fails, we can still redirect requests to the others.
- Auto scaling is very easy with deployment platforms like Kubernetes.
- This makes horizontal scaling very responsive to an application’s fluctuating demands, leading to high availability.
Cons
- We have to use a load balancer to distribute the requests across the different instances.
-
Could introduce network calls (RPCs) for coordination even in monoliths, leading to more complexity and increased latency.
-
It is harder to maintain data consistency, especially if each instance has its own independent copy of the DB (big big no).
-
If we use a strategy where we have one primary write-DB and multiple read replicas, we are still left with eventual consistency in our read operations because the read replicas are updated asynchronously so that write performance is not affected negatively.
- If we decide to shard the DB so that each instance owns a portion of the data, then fetching data which may exist in different instances might become very hard.
-
This might require us to denormalize the database so that joins are less frequent, but this would introduce duplicated data.
-
If we want to apply transactional operations and the data is spread over different instances, this will be hard unless we use the Saga pattern, which is more complex than traditional transactions on a single DB.
Vertical Scaling
Pros
- Data consistency.
- Does not introduce the added complexity that comes with a load balancer.
- Communication always stays within the same app (no RPCs).
- Transactions are easy to implement as we are dealing with a single DB.
Cons
- We can only upgrade a single machine’s capabilities so much until we hit a limit.
- Might have availability issues because the app must be re-deployed when we change the machine’s resources, leading to possible downtime.
- Single point of failure.
Wrapping Up
- Vertical scaling is simpler but limited in growth and has a single point of failure.
- Horizontal scaling is more resilient and easier to grow, but comes with complexity in coordination, consistency, and transactions.
Think of it like this:
- Vertical scaling is putting a bigger engine in one car.
- Horizontal scaling is adding more cars to your fleet.
All in all, scaling is one of those things that looks simple on paper but gets tricky fast once you factor in real-world trade-offs. Both approaches have their place, and which one you choose depends on your app’s needs and constraints.
Which scaling approach have you used before, and what challenges did you run into?