How do you approach designing ANY system and selecting appropriate AWS services as a Solutions Architect? When you look at any complex application, it looks daunting, and you have no idea how to get started. And yes, I have been there too! In this newsletter edition, I will reveal the framework I have developed and used with my customers, as well as in interviews successfully.

First, break down the application into logical layers as below

• Consumption - How will the end customers consume information
• Processing - This layer processes the input and executes business logic.
• Storage - Next is the storage layer. As the name suggests, data will be stored in this layer
• Ingestion - If your application needs to have some prepopulated data, for e.g. product prices and product pictures that your application is selling, these can be loaded to the storage using this layer

This is following First-Order Principal Thinking, where you break down a large problem into small, logical, solvable chunks. Instead of one BIG solution, think about Lego blocks.

Once you have these logical layers, you can apply the non-functional requirements to them. Some of the common non-functional requirements are scalability, high availability, security, etc.

Now let's take an actual example, and implement this. Let's take a retail website. The layers will look like below:

Now that we have the layers, we need to select appropriate AWS services for them. There are many choices for the layers.

• The consumption and processing layer can run on Amazon EKS, EC2, or Lambda. Load Balancers or API Gateways can handle the traffic interface.
• Storage can be either NoSQL like Amazon DynamoDB, or SQL database like Amazon Aurora, or maybe a combination of both!
• The ingestion layer can be done via AWS Step Functions.

Select services based on functional requirements, non-functional requirements, and priority of well-architected pillars. In certain cases, factors like existing tech stack, knowledge of the existing team, licensing terms, time to market, etc., will come into play.

One mistake that architects and interview candidates make is thinking that every design has the same non-functional requirements. For example, a retail website must be highly scalable because millions of customers will be accessing it at the same time. But think of a parking garage. A parking garage has limited spots available, so the database and even the consumption and processing layer don't require to be anywhere as scalable compared to a retail website.

Every design decision involves a tradeoff. For example, if your application requires inspecting traffic before processing, you are implementing additional security, but the latency and cost will be higher.

Let's assume the team is just starting its journey in AWS, and the operations team is comfortable with handling VMs. For that reason, they chose EC2s for the consumption and processing layer, ALBs for interfacing with the traffic, and Amazon Aurora MySQL for DB. For this discussion, we are focusing on the more critical layers, consumption processing storage, and keeping the ingestion layer aside. The architecture will look like the following:

Now that we have AWS services for each of the layers, we can turn our attention to the non-functional requirements and implement them in each layer. Let's say we want to implement scalability and high availability to the layers:

• ALB is inherently highly available and scalable, so no action is needed
• To make EC2s highly available, you need at least two EC2s running in two different Availability Zones
• To make EC2s scalable, you will implement Auto Scaling Group to scale them horizontally
• You can implement the multi-az feature in Amazon Aurora to make it highly available. Relational databases can't be scaled horizontally in a straightforward way, but implement sharding and read replicas to sustain heavier traffic.

So the resulting architecture will look like this:

Once you have this architecture, you can keep implementing other non-functional features and keep on optimizing it.

Now that we have covered how to create an AWS system design from the requirements, can you think about implementing this framework for other popular applications?

If you have found this newsletter helpful, and want to support me 🙏:

Checkout my bestselling courses on AWS, System Design, Kubernetes, DevOps, and more: Max discounted links​

AWS SA Bootcamp with Live Classes, Mock Interviews, Hands-On, Resume Improvement, and more (next cohort will launch in September): https://www.sabootcamp.com/​

​

Keep learning and keep rocking 🚀,

Raj