Vertical scaling versus horizontal scaling in database systems

Photo by Markus Winkler on Unsplash

In the world of system design, there is one question that will consistently come up: how do we scale when the amount of requests exceed what our servers can handle.

Today we will talk about two type of scaling with database systems: vertical scaling and horizontal scaling.

Photo by Ana Pereira on Unsplash

Vertical scaling, known as scale up, involves adding more CPU cores, adding more RAM into a server to increase its capacity. For example, if you have a server that can handle 1000 requests per second and has 20 GB(it is just some arbitrary numbers) and you want to scale up, you will be allocating 40GB to handle 2000 requests per second, let’s say.

Of course, these are all arbitrary numbers but the idea is clear.

Photo by Dave Hoefler on Unsplash

How about horizontal scaling?

Instead of allocating more CPUs, we are creating more replicas of the servers and use a load balancer to distribute this load.

Let’s take a look at the follow diagram:

Over here, we added additional databases that are made available for any transactions. If there are 2 million requests, these 2 million requests would be handled across different databases. This is known as database sharding, which is the concept of distributing workload across multiple database instances.

On the image, we will have one primary db instance, which is mainly used for writing while having multiple db instances that is used for reading.

Question is, how do we know which requests goes to which database?

When the system receive client requests, we can utilize the ids that are passed in the request. Afterward, we can use a hash function to dictate which database to point to for the reading. If this is a request for writing data into the database, we can skip the hash function and simply connect to the database specified for writing.

Once the database for editing data has finished its transaction, it will automatically send a message to other read databases to sync up with the write database.

Photo by Kelly Sikkema on Unsplash

Now that we have talked both types of scaling, let’s talk about the pros and cons of each approach.

Pros of vertical scaling:

• simple management: instead of managing about multiple database instances, we only have to manage one database server.
• performance improvement: it improves the performance of one single server by simply allocating more CPUs and ram.
• Cost-effectiveness: it can be cost effective for small to medium systems since upgrading a system can be cheaper than scaling it up depending the size of the system.
• Single point of control: since there is only one database instance, all the data goes here. It is easy to maintain control and provide security to one node instead of multiple nodes, where we have to worry about syncing up data.

Cons of vertical scaling:

• limited scalability: this is one of the major flows of vertical scaling. With vertical scaling, you can only add some much CPU and RAMS to the hardware. And let’s say the maximum amount of request the system can handle is 5 million requests. What happens if the system needs to scale beyond that? Obviously there is a hard limit as to how much vertical scaling we can do, so this can be a problem for big and complicated systems.
• single point of failure: we previously talked about having a single point of control. While it is easy to control the data flow and handling one server but it also means there is a high risk of maintenance and down time if something happens to the server. In many big applications today, that is simply not acceptable.

Photo by Miguel Arguibide on Unsplash

Pros of horizontal scaling:

• scalability: as the system becomes more complex, we can simply add as many database instances and nodes as possible. There is no hard limit as to how many nodes we can add.
• fault tolerance: the system would be more resilient since we would have multiple nodes to backup if one of the database instance fails. For example, let’s say we have 5 nodes. Something happen to one of the nodes and fail before some requests goes toward that node. What happens is these requests get redirected to other nodes in the system. Eventually, that failed node would be terminated and a new node will be introduced into the system. That way, we would not have to worry about downtime since there will always be database nodes available to run and handle requests.

Cons of horizontal scaling:

• Complexity: it is more complex to distribute workload to multiple nodes instead of sending it all to one node. In this case, a load balancer would need to implemented.
• Communication: this points back to complexity. Since we are dealing with more nodes, these nodes will communicate(whether it is syncing up data or other form of communications). As the system scales up, the communication can also become more complicated.
• cost: As the system scales up, it can get expensive to maintain all the nodes in the system.

Overall, if you are designing a small application, you probably shouldn’t worry about sharding databases or using a load balancer(horizontal scaling). However, if you are design an application that will become increasingly complex, then horizontal scaling is the way to go.