Three-Tier Architecture Diagram: Presentation, Application and Data

Three-tier architecture is the shape most web applications still have under the hood: something that serves the user interface, something that runs the business logic, and something that stores the data. It is old, it is boring, and it is the right starting point for most systems, because each tier can scale and be secured on its own.

This post explains the three tiers, shows how they map to a cloud network with subnets and security groups, and draws a typical AWS deployment across two availability zones. The same structure works on any cloud.

The three tiers

The rule that makes it an architecture and not just three boxes: each tier only talks to its neighbor. The browser never reaches the database, and the presentation tier never runs SQL.

AWS describes the pattern in its three-tier architecture overview, including serverless variants where functions replace application servers.

Mapping tiers to the network

Tiers become real boundaries when they live in different subnets with different routes:

• Public subnets hold only what must be reachable from the internet: the load balancer and NAT gateways.
• Private application subnets hold app servers. They can reach the internet outbound through NAT for updates and APIs, but nothing can reach them from outside except through the load balancer.
• Private data subnets hold databases and caches, with no route to the internet at all.

Security groups then allow only the neighbor's traffic: the database accepts port 5432 only from the app tier's security group, not from an IP range. Referencing groups instead of addresses keeps the rules correct as instances come and go.

High availability across zones

Run every tier in at least two availability zones:

• The load balancer spans zones by design.
• App servers run in an autoscaling group with instances in each zone. If a zone fails, the others take the traffic and the group replaces capacity.
• The database runs with a synchronous standby in another zone. With Amazon RDS Multi-AZ, failover to the standby is automatic, and the endpoint name stays the same.

Keep the app tier stateless so any instance can serve any request: sessions go to a shared cache or database, uploads to object storage, and nothing important lives on an instance's disk. Test it by terminating a random app server during business hours; if users notice, some state is still hiding on the instances.

Scaling each tier

Tiers scale differently, which is the reason to keep them apart:

• Presentation: a CDN absorbs most static traffic. Cache headers decide how much.
• Application: add instances. Scale on request count or CPU, and keep instance startup fast.
• Data: the hardest. Scale up first, add read replicas for read-heavy load, add a cache for hot keys, and treat sharding as a last resort.

One request through the tiers

Follow a user loading their order history:

1. DNS returns the CDN's address. The browser requests the page; HTML, scripts and images come from the CDN's cache or the static bucket behind it.
2. The page calls GET /api/orders. The CDN forwards dynamic paths to the load balancer, which terminates TLS and picks a healthy app server in either zone.
3. The app server reads the session from the cache, checks that the user is signed in, and queries the primary database for the orders.
4. The response travels back through the load balancer and the CDN, which does not cache it because the response is private.

Every hop crosses one tier boundary, and each boundary has exactly one allowed entry point. That is what makes the design easy to reason about and to secure.

Costs and right-sizing

The data tier usually dominates the bill and is the hardest to shrink later, so size it from measurements, not guesses. The application tier is the easiest to tune: start small, scale on real load and let autoscaling handle peaks. NAT gateways and cross-zone traffic are the line items that surprise people; keep chatty traffic inside one zone where you can, and use VPC endpoints for object storage so app servers do not pay NAT charges for every upload.

The architecture diagram

How to read it:

• Top: users resolve DNS and connect to the CDN, which serves static files from a bucket and forwards dynamic requests.
• Presentation tier: the application load balancer is the only component in public subnets.
• Application tier: app servers in zones A and B sit in private subnets and receive traffic only from the load balancer.
• Data tier: the primary database in zone A replicates synchronously to a standby in zone B; app servers also use a session cache. This tier has no route to the internet.
• The Markdown block lists the security group rules, which are the real enforcement of the tiers.

Common mistakes

• Databases in public subnets "temporarily", for a quick query from a laptop. Use a bastion or a managed session tool instead.
• Security groups that allow a whole CIDR range between tiers instead of referencing the neighbor's group.
• State on app servers: sessions in memory, uploads on local disk. Autoscaling and failover then lose data.
• A single availability zone for the database to save money, with the app tier spread across three.
• Skipping the CDN and serving every image from app servers.
• No health check path on the app servers, so the load balancer keeps sending traffic to instances that cannot reach the database.

When three tiers is not enough

Three tiers describe one application. As a system grows into several services, each service often keeps its own three-tier shape, and the diagram moves up a level to show how the services talk to each other. The microservices architecture diagram covers that step. For the network details, see the AWS VPC diagram, and for more than one region, the AWS multi-region architecture diagram.

Build it in Archboard

1. Sign in with Google or GitHub and create a diagram.
2. Add a Person from the C4 Model pack, a DNS from the Network pack, and a CDN and an Object Storage node from the Cloud pack.
3. Add a VPC from the Network pack and three Frame nodes from the Core pack inside it, one per tier.
4. Add a Cloud LB to the presentation tier, two Compute nodes to the application tier, and two Managed DB nodes plus Redis from the Data pack to the data tier.
5. Connect each tier only to its neighbor and add a Markdown block from the Core pack with the security group rules. If your setup already exists as Terraform, the Terraform to diagram tool gives you a first draft.

The example uses 15 diagram nodes, within the Free plan.

FAQ

What are the three tiers in a three-tier architecture? Presentation (the user interface and entry point), application (business logic and APIs) and data (databases, caches and storage).

Is three-tier architecture outdated? No. It is the default shape for web applications. Microservices and serverless systems still contain the same three responsibilities, often per service.

What is the difference between three-tier and three-layer architecture? Layers are a logical split inside the code; tiers are a physical split across separate machines or services with network boundaries between them.

Should the database be in a public subnet? No. Keep it in private subnets with no internet route, reachable only from the application tier's security group.

How do I make a three-tier application highly available? Run each tier in at least two availability zones, keep app servers stateless, and use a database with an automatic standby in another zone.

Start free — one seat, no credit card.