One of the primary components of having a robust architecture is the ability for your systems to scale based on their needs. This is especially important when we are talking about your database. 

Your database can scale based on two primary attributes, its read capacity needs or the write capacity needs. It may not seem very obvious at first, but in practice the ways you scale your database for these problems differ fairly heavily. Let's take a moment to go over some definitions so we are all on the same page.

Scaling from a read point of view would occur if you had an increase in traffic that primarily needed to retrieve information from the database. 

For example: an online video game might have a lot of people accessing the all time high scores page, to see how their games compare to the record holders.  However not many people statistically are going to be able to put up new high scores that often, making this a read heavy workload.

You might have the opposite scenario when tracking the activities of the players playing your online game. 

Let say you were very interested in completion metrics and other analytical data about the progress of your players. In this scenario you would be writing to your database very frequently and only reading the information gathered every once in a while to create a report. This would be called a write heavy workload.

There are scenarios where your workload will increase proportionally - where neither the write or the read are the constraining factors themselves. This is the preferred case, because it's the most straightforward to alleviate. We will go more into that soon.

Now that we have an idea on why our database would need to scale, let's take a look at the options available to do so. There are two ways to deal with scaling your database, you can scale horizontally or you can scale vertically.

Scaling vertically is generally the easiest method of scaling. This is where you increase the size of the underlying hardware / software to help deal with the problem. Providing more raw power for transactions like reading and writing. 

Vertical scaling is a very good solution if you have equal levels of reads and writes, as you get proportional increases in both when you upgrade the underlying hardware. It is also a fine strategy for dealing with reads or writes individually, but that might not be as cost effective.

Vertical scaling is all about increasing the horsepower of the database you already have, allowing you to do more work. 

Some things to consider when you scale vertically:

There is time involved when changing your instance types and this can increase downtime for your applications. Something to be aware of if you have strict SLAs you need to adhere to.

There are upper limits for how many times you might be able to vertically scale. As you scale vertically and work your way up the hardware/instance ladder, you will eventually reach a ceiling. Over time this ceiling will move upwards as new technologies become available - but I wouldn't hinge my project on it.

Still requires standby databases to be available in case the primary where to go offline. Scaling vertically doesn't really help address issues with fault tolerance.

The other method we have available is to scale horizontally. This means increasing the number of underlying hardware or software entities to improve performance. Increasing the number of entities allows more surface area for your transactions to communicate with. 

Scaling horizontally does come with the downside of losing finite control over your database by removing some of the intelligence you get with just having one source of truth. Managing the routing of each additional entity, updating more entity systems in general, and dealing with consistency problems across these databases can be difficult to do.

Do not let that deter you if scaling horizontally is the right answer for your architectures. Because as we will discuss in the next section, RDS has many features already built into it that can handle these problems for you.

Overall horizontal scaling works very well for dealing with read capacity issues. However there are some extra steps involved to scale write capacity when speaking about single node master systems. ( databases where there is only a single write source)

Unlike vertically scaling, horizontal scaling lends itself towards greater fault tolerance and high availability - since your data will already be split up and be in a better position to survive portions of the database failing.

Lectures

Course Introduction - Scaling with RDS - Course Summary