How to scale an application to millions of users using AWS

Many companies face the challenge of application scalability while in the process of developing and maturing their applications. For the purpose of improving my knowledge in this field and putting it into practice in the future, I participated in the webinar "Using AWS to scale to millions of users this Black Friday", offered by Amazon.

The main question developed during the webinar was: what type of architecture can handle more than a million users? To answer this question, it is necessary to dive further into what is needed to make an application scalable.

There are two types of architectures that applications fall into: monolithic and microservices. Monolithic architectures happen when an application has tightly coupled components, such as databases, servers, business logic, and the user interface, in a unified unit. If a single component fails, the entire app may fail because there is no disaster proofing such as redundancy.

For microservices architectures, however, there can be multiple units of a single component that are loosely coupled. That is, if a single component fails, others can continue working because there is communication between the components. The latter is a better approach because it enables redundancy, and makes it easier to scale up by just adding more units.

The first step that can be taken to separate the moving parts of an application and transform it into microservices is to detach the database from the instance running, that way, if the instance fails, the database will still be accessible. AWS offers different types of databases, such as Amazon Aurora, a Relational Database that offers conínuous and incremental backups, with the advantage of having the storage and processing layers decoupled, unlike other SGBTs like Oracle and SQL Server.

So far, the architecture may look like this:

Amazon Route 53 is used as a DNS (Domain Name Service), it translates the website’s names into IP addresses and directs the traffic coming from the users into a VPC (Virtual Private Cloud) that isolates the AWS resources from users, reducing the attack surface for potential hackers.?

To scale horizontally, more instances can be added, but that can lead to a problem of bad distribution, as one instance may have more requests than the others. To solve this problem, a load balancer such as Amazon Elastic Load Balancer can be used to distribute the workload of the instances, which also decreases waiting time for requests that wait in a queue.

As more instances are added, more requests will be made to the database, which can cause overhead. For this, it is possible to use specialized read replicas of the database, thus taking a lot of the load off the primary instance. It is important to note that the replicas are asynchronous and must not be used for actions that do not tolerate information delay.

To further take load off the instance, static files such as images, videos and javascript code can be stored into an S3 Bucket, an Object Storage Service that has cryptography at rest and transit. These static files can then be delivered efficiently through Cloudfront, a service that stores these files in a cache at an Edge location, which is separate from Regions. This means that it is possible to push content from inside a Region to a collection of Edge locations around the world, closer to the final user, in order to accelerate communication and content delivery.

Still on the subject of cache, Amazon ElastiCache can be used to distribute database loads and improve performance, while DynamoDB can store user session data.

AWS also provides auto-scaling groups capable of scaling resources such as EC2, Amazon Aurora replicas, and DynamoDB instances. The scaling factors to be considered are the velocity at which it is possible to increase and decrease resources; how much can be altered; and how is the pricing structured relative to capacity and time. To better understand when to scale up or down, services such as Amazon Cloudwatch can generate live statistics. These statistics are then used in auto scaling groups.

As suggested by the host, the final version of the architecture could utilize lambda functions, e-mail services, and others, according to the needs of the application being executed.

It is possible to observe that by separating the moving parts of an application, it becomes easier to add redundancy and communication between the units to provide scalability, fault tolerance and better performance, improving the end user experience.