If we take the three issues stated earlier, we can solve each of them in one or two ways. Let's look at them first:
Issue #1: Out of memory
Solution:
- Due to the database: Increase RAM for the database
- Due to the blog server: Increase RAM for the blog server
Issue #2: Performance degradation
Solution:
- Due to the database: Increase the CPU power for the database
- Due to the blog server: Increase the CPU power for the blog server
Issue #3: Out of storage space
Solution:
- Due to the database: Increase the storage space for the database
Using this listing, we can upgrade our system as and when required for a particular problem we are facing. However, we first need to correctly identify the component that is causing the issue. For this reason, even before we start scaling our application vertically, we should separate our database from our web server as shown in this figure:
This new setup with the database and the blog server on separate server instances would enable us to monitor which component is having an issue and vertically scale only that particular component. We should be able to serve a larger user traffic with this new setup.
However, as the load on the server increases, we might have other issues on our hands. For example, what would happen if our blog server were to become unresponsive? We would no longer be able to serve blog posts and no one would be able to post comments on said blog posts. This is a situation no one wants to face. Wouldn't it be nice if we could keep serving traffic even if the blog server were down?