1. Home
  2. Training Library
  3. Amazon Web Services
  4. Courses
  5. Deploying a Simple Business Application for Pizza Time

How we can increase the Availability and Scalability of our Database


Welcome to Pizza Time!
Deploying the First Iteration of Our Business Application
Adding Analysis, Monitoring and Cost Management
Start course
Duration1h 44m


In this group of lectures we will introduce you to the Pizza Time business and system requirements. Pizza Time requires a simple ordering solution that can be implemented quickly and with minimal cost, so we will do a hands deployment of version 1.0 of our solution. To achieve that we are going to use a single region and deploy an application using AWS Elastic Beanstalk. We will implement a simple database layer that will be capable of delivering on these initial requirements for Pizza Time. 

It turns out that the Pizza Time business is a success and the business now wants to target a global audience. We discuss and design how we can increase the availability of our initial Pizza Time application, then begin to deploy V2 of Pizza Time - a highly available, fault-tolerant business application. 



Hi, and welcome to this lecture.

In this lecture, we are going to cover high availability topics for RDS. We are going to talk about Multi-AZ. We are going to talk about read replicas, and cross-region read replicas.

As you might probably know, a Multi-AZ database spans across two availability zones. The main benefit of it is having automatic failover. If something happens with the main database, if there is a fire in the AWS data center, your database will failover to the standby database automatically.

So what happens is you have two databases, and you have a synchronous replication between them. And these databases will live in different availability zones, so that will ensure that you have high availability within a single region. You can also get some other benefits, like during maintenance windows when you need to update your main database. So your main database will be offline. The standby database will become the master database. After that, AWS will also update the standby database so the standby database will became again the standby database, as the main database will became again the main database.

So read replicas are kinda the same, but you don't have a synchronous replication between the two instances. Instead, you have in a synchronous replication. And what that means is that AWS will not ensure that everything there is in the main database will be in the read replica database. You can use a read replica to offload the traffic in your main database and you can route all the read requests through the read replica database.

You can also use the read replica for failover purposes. For example, if this whole availability zone goes down, or if you have a problem with the main instance, then you can promote a read replica instance. And this instance will become the master instance.

It's very easy to promote a read replica through a master instance. You actually have an option to do that in the RDS console. We just need to select the RDS database, go on Instance Actions, and select Promote Read Replica in case you have selected a read replica database.

Cross-region read replicas are also available, so you can offload the traffic from your application in other regions using read replicas. And you can promote the cross-region read replica.

You can also use cross-region read replicas for backup and disaster recovery scenario. What you have then is a main database, so you can send all the right requests through this database. And if you have a Multi-AZ database, you also have another standby database within the same region in a different availability zone, so each of these databases will be in a different AZ. And if there is a problem, you have automatic failover for these database instances.

You can also offload the traffic of your database by creating a read replica, and forwarding all the requests through this read replica instance. But remember that this will be in a synchronous replication, so not everything that you have on the main database will be available on the read replica. The replication will not be that fast, so you might have some latency in your replication.

And, if you need to have even more protection, in a case of a disaster, or even more high availability, you can also have a cross-region read replica. You replicate your main instance through a read replica in a different region, and remember that this replication will also be a synchronous, and this replication will be even slower than the read replica within the same availability zone, because this replication will go through the Internet. And even AWS, having a super fast Internet connection, there will be some latency in your replication.

But the great thing is that, imagine that the whole region goes down. You have an outage. And that can happen. In the end, a data center will still be a physical location, so in case of a hurricane or something like that, you might have an entire region going down. And it will be very useful for you to have a cross-region read replica, because as I said, you can promote this read replica to be your main database.

And you can also use this read replica to offload the traffic of your application. When we are dealing with applications that are served for the entire world, that will be very useful, because you can forward the requests through a data center closer to your clients.

About the Author

Eric Magalhães has a strong background as a Systems Engineer for both Windows and Linux systems and, currently, work as a DevOps Consultant for Embratel. Lazy by nature, he is passionate about automation and anything that can make his job painless, thus his interest in topics like coding, configuration management, containers, CI/CD and cloud computing went from a hobby to an obsession. Currently, he holds multiple AWS certifications and, as a DevOps Consultant, helps clients to understand and implement the DevOps culture in their environments, besides that, he play a key role in the company developing pieces of automation using tools such as Ansible, Chef, Packer, Jenkins and Docker.