Hello Reader,

As a former Principal Solutions Architect at AWS, and a Distinguished Cloud Architect at Verizon, I have conducted over 300 interviews, and helped many students crack Big Tech interviews.

If there is one system design you absolutely must know before walking into a cloud interview, it is this one.

Three-tier architecture.

It shows up everywhere - in interviews, in real-world enterprise projects, and in almost every production application you interact with daily.

Amazon.com is a three-tier architecture.
Your banking app is a three-tier architecture.
The checkout flow you used last time you bought something online - three-tier architecture.

And yet, most candidates answer questions about it at a surface level. Today we go deeper.

The Three Tiers - What They Actually Are

The name is straightforward: three distinct layers, each with a specific job.

Presentation layer - this is your front end. The website or app your user sees and interacts with. Think amazon.com where you browse products and click "add to cart."

Application layer - this is your backend. The moment you click that button, business logic kicks in. Is the item in stock? Is the user eligible? What is the shipping address? All of that runs here in Java, Python, Node.js, or whatever language the team chose - before anything touches the database.

Database layer - this is your persistence. SQL or NoSQL depending on your data model. Everything gets saved and retrieved here.

Three distinct responsibilities. Three independently managed layers. That is the whole point.

The Mistake I Hear The Most in Interview

I can't tell you, how many times I have heard this:

"Presentation layer is ALB, application layer EC2s with ASG, and then a database".

This is wrong, please don't do this mistake.

Below is the correct design of three tier architecture:

1. First layer is presentation layer.
   ​Customers consume the application using this layer. Generally, this is where the front end runs.
   ​
   For example - amazon.com website. This is implemented using an external facing load balancer distributing traffic to VMs (EC2s) running webserver.
   ​
2. Second layer is application layer.
   ​This is where the business logic resides. Going with the previous example - you browsed your products on amazon.com, and now you found the product you like and then click “add to cart”. The flow comes to the application layer, validates the availability, and then creates a cart.
   ​
   This layer is implemented with internal facing load balancer and VMs running applications.
   ​
3. The last layer is the database layer.
   ​This is where information is stored. All the product information, your shopping cart, order history etc. Application layer interacts with this layer for CRUD (Create, Read, Update, Delete) operations.
   ​
   This could be implemented using one or mix of databases - SQL (e.g. Amazon Aurora), and/or NoSQL (DynamoDB)
   ​

The presentation and app tier can be built with microservices with ALB, EC2, and optionally Database. Separate target groups handle each microservice. Each functionality can be backed by different compute options.

For example, /browse is being served by EC2 + Auto Scaling Group, /buy is being served by AWS Lambda, and Kubernetes are serving others.

Instead of a database, one microservice can call another microservice with internal facing ALB to perform certain business functions, assuming the presentation and app tier teams are separate.

Not only these three microservices are handling different functionalities, but they can also be coded in different languages. For example, /browse is written in python, /buy in Node JS, and /* in Go. This property is called polyglot

Here are some popular follow up questions:

The Single Point of Failure Question - "What components are single point of failure in three tier architrecture?"

Load balancers are not a concern - AWS runs them across multiple Availability Zones under the hood. That single icon on your diagram is actually highly available infrastructure you do not manage.

Your EC2 instances for the web and app tiers are the real risk. A single EC2 is a single point of failure. The fix: put both tiers into Auto Scaling Groups spanning at least two Availability Zones, with a minimum of two instances running at all times. Now if one AZ goes down, your application keeps running.

Your database is also a risk, and you have to make it Multi-AZ for RDS. DynamoDB is highly available. For Aurora, storage is inherently highly available, you need to make the writer instance Multi-AZ to be highly available.

The Network Security Question - "How do you secure this design from a network perspective?"

Interviewers love this one.

The rule: put as much as possible in private subnets. The only component that should live in a public subnet is the internet-facing load balancer at the very front. Everything behind it, web servers, app servers, databases, goes in private subnets where the internet cannot reach them directly.

Layer on other security controls and services - WAF, Shield, Security Group, NACL etc.

The Scale Question - "How do you handle high traffic day with three tier?"

Hopefully, all of you read our previous emails!

We went over pre-warming, warm pools, scheduled scaling, lightweight AMIs, Caching, RDS Proxy, AWS Countdown, and account limits.

If you missed it, go back to your mailbox and check it out for deep explanation.

Keep learning and keep rocking 🚀,

Raj

P.S - If you want to get an AWS Solutions Architect job without coding or learning every AWS service, the 8th cohort for AWS SA Bootcamp is launching on May 16th, 12 PM ET (Eastern Time) via live webinar. Please register for the webinar below:

Here’s what you get when you show up LIVE:

1. My exclusive Solutions Architect framework to prep you for today's job market! But if you’re not live, you won’t get it. No second chances.
2. Full bootcamp details, my new stealth product reveal to help you prepare better, AND a special offer for live participants only.
3. You will have the chance to interact with me and ask questions.

And good news - it already worked for last cohort's students who secured cloud jobs in top companies, including at AWS, Microsoft, Google, JPMorgan, Reddit, and some of them didn't even have cloud experience 💰.

Spots are limited, so don't miss it!