0% completed
Scalability
On This Page
Horizontal Scaling
Vertical Scaling
The Difference That Decides It
MySQL is an example here, not a rule
Scalability is the ability of a system to handle an increasing workload, either by adding more resources or by making the existing ones bigger.
Those are the two directions, and they have names.
Horizontal Scaling
Horizontal scaling, also called scaling out, means adding more machines or nodes to a system so the workload is distributed evenly across them.
No single node has to absorb the growth. More requests arrive, more machines share them.
This suits distributed systems well. Capacity can be added while the system runs, which makes it a cost-effective way to handle workloads that rise and fall, and having many machines is what makes high availability possible in the first place.
Cassandra and MongoDB are good examples. Both are built so you add machines to meet growing demand.
Vertical Scaling
Vertical scaling, also called scaling up, means increasing the capacity of an individual node by upgrading its hardware: more CPU, more memory, more storage.
The same single machine now handles more work.
MySQL is a good example. Moving from a smaller machine to a bigger one is a straightforward way to get more capacity, and the process usually involves downtime.
The Difference That Decides It
Horizontal scaling is easier to do dynamically. You add machines to the pool that is already running.
Vertical scaling is bounded by a single server's capacity. Growing past that ceiling usually means downtime, and there is an upper limit you eventually hit no matter what you spend.
| Horizontal (scaling out) | Vertical (scaling up) | |
|---|---|---|
| What changes | Number of machines | Size of one machine |
| Ceiling | Practically far away | The biggest machine available |
| Adding capacity | Add nodes to the running pool | Usually needs downtime |
| Failure of one node | The others carry on | Everything is on that node |
| Examples given | Cassandra, MongoDB | MySQL |
Read the last two rows together, because that is where the risk lives. Relying only on vertical scaling has two problems at once: there is a physical ceiling on how big one machine can get, and putting everything on that one machine creates a single point of failure. The system gets faster right up until the moment it is completely down.
MySQL is an example here, not a rule
The examples above line up as NoSQL on one side and relational on the other, and that is not where the real line sits. Relational databases can be scaled horizontally, and several widely used systems do exactly that:
- Vitess puts a sharding layer in front of MySQL and routes each query to the right shard. YouTube and Slack run on it.
- Citus is an extension that turns PostgreSQL into a distributed database by spreading tables across nodes.
- CockroachDB, Google Spanner and YugabyteDB are built to scale out from the start, while still speaking SQL and offering transactions.
What is true is that scaling a relational database out takes more work than scaling out a system designed for it from the beginning. Once the rows of one table live on different machines, a join across shards has to pull data over the network, and a transaction touching two shards needs a distributed commit. Both are slower and more complicated than their single-machine versions. Cassandra sidesteps the problem by not offering cross-node joins at all, which is a restriction rather than a magic property.
So the accurate sentence for an interview is not "relational databases cannot scale horizontally." It is "sharding a relational database costs me cheap joins and cheap transactions across shards, so I would either choose shard keys that keep related rows on the same node, or use a database built to scale out."
Real systems combine the two. A service can run on many machines and also give each machine more CPU or memory when individual tasks are heavy. Scaling both ways at once is sometimes called diagonal scaling: bigger machines, and more of them, for the same workload.
💡 In an interview, do not just say "I would scale horizontally." Say what makes it possible. Horizontal scaling only works if requests can go to any node, which means saying where the state lives. "The service is stateless, so I can put any number of instances behind a load balancer, and session state goes in a shared cache" is the actual design.
Key takeaway: Scalability is handling more work by adding resources. Horizontal scaling adds machines and spreads the workload across them, which is the approach distributed systems are built for. Vertical scaling makes one machine bigger, which is simple but limited by that machine's ceiling, usually requires downtime, and concentrates everything into a single point of failure.
The next lesson, Availability, covers what it takes to keep a system reachable once it is spread across many machines.
Akshay M
· 6 days ago
We can achheive horizontal scaling for relational db using Vitess and citus as well . Plus we have Cockroach , spanner and Yugabyte like DB for it
dinko.osrecki
· 2 months ago
What is missing here is diagonal scaling (combined horizontal and vertical scaling of the same workload).
Imagine an application that is processing tasks of variable complexity and load. It can happen that servers are hit with a huge batch of highly complex tasks (while normally it processes steady number of tasks of lower complexity). In this case it makes sense to scale both vertically (more CPU/RAM to have capacity to handle a complex task) and horizontally (many tasks to process).
Shrikrishna jagdale
· a year ago
Normally in spring boot application we write validation checks for the request content, e.g headers, request body fields. What if we offload this validation to api gateway and let the application assume that only valid requests will land on the application's controller?
Fayaz S
· 3 years ago
what should be our approach or things to consider or how to start with if we are trying to design a scalable and high performing platform and cloud analytic monitoring solutions
Reading Progress
0%
On This Page
Horizontal Scaling
Vertical Scaling
The Difference That Decides It
MySQL is an example here, not a rule