Skip to main content
System Design Mafia
Back to patterns

Layered Architecture

Traditional n-tier architecture organizing code into horizontal layers with strict dependency flow.

//The Contract

Requirements

Functionalwhat the system must do
  • ✓A user's request flows strictly downward — presentation to API to business logic to persistence to database — and the response flows back up the same path
  • ✓New business rules are added inside the Business Logic Layer without the Persistence Layer or the database schema needing to know about them
  • ✓The Presentation Layer can be restyled or replaced (web, mobile) without changing any business logic, as long as it still talks to the same API Layer
  • ✓The Persistence Layer can change ORMs or query strategies without the Business Logic Layer noticing, as long as its interface contract stays the same
Non-functionalhow well it must do it
  • ≫Each layer only depends on the layer directly beneath it — no layer skips a layer, and no layer calls upward
  • ≫The system is easy to reason about for newcomers — a request's path through the code is always the same four hops, in the same order
  • ≫Because everything runs in one deployable unit, a change anywhere requires redeploying the entire application
  • ≫The database absorbs the full load of every request, since there is no cache or read-side shortcut in this design
//Back of the Envelope

Scale Estimates

Rough, order-of-magnitude numbers. The point is to justify the architecture, not to be exact.

Layers
5
UI, API, business, persistence, database — a fixed, well-known hop count
Deploy units
1
the whole application ships and scales as a single monolith
Typical team size
1-2 teams
layering alone doesn't force team boundaries the way microservices do
Cross-layer shortcuts allowed
0
strict layering forbids skipping a layer, even for a 'quick' read
//Follow the Data

Request Flows

A diagram shows what exists; a trace shows what happens. Press play on a flow, or click any step, and the diagram above lights up the exact path that request takes.

Flow 01

Handle a user request

The one path every request takes, in both directions.

Flow 02

Why a layer never skips down

The rule this pattern enforces, and what it costs to keep it.

//Component Breakdown

Key Components

Every box on the canvas, and the job it does. Click a card to locate it in the diagram; click the node itself for the full deep dive.

client×1
network×1
compute×1
database×2
//Deep Dive

Architecture Breakdown

A Fixed, Predictable Path

Layered Architecture organizes an application into horizontal tiers, each depending only on the tier directly beneath it. It is the most traditional way to structure a monolith, and its main virtue is predictability: any request's path through the codebase is always the same fixed sequence of hops, in the same order, with no exceptions to memorize.

The Five Layers

  • Presentation Layer — faces the user, translates input and output, contains no business rules of its own
  • API Layer — exposes a stable contract and routes into the business tier
  • Business Logic Layer — the only place domain rules are enforced
  • Persistence Layer — the only code allowed to construct a query or call an ORM
  • Database — the actual data store, spoken to only by the layer directly above it

The Rule That Matters

The entire value of this pattern rests on one constraint: no layer skips a layer. The API Layer never queries the Database directly, and the Presentation Layer never touches Persistence, even when a shortcut looks harmless. Enforcing this consistently is what keeps the dependency graph simple enough to reason about — the moment shortcuts are allowed for convenience, the graph stops being layered at all.

The Trade

Strict layering buys simplicity and a single deployable unit at the cost of two things: every request pays for the full hop chain even when most of it is unnecessary overhead, and the whole application has to scale together even if only one layer — usually the database — is actually under load. Those costs are exactly what patterns like CQRS or hexagonal architecture exist to relax, once a system outgrows this one's assumptions.

//Trade-offs

Design Decisions

An architecture is a record of trade-offs. For every major choice here: what won, what lost, and why the constraints made it so.

01

Strict layering — no skipped layers

ChoseEvery call passes through all five layers in order
OverAllow a layer to call two levels down for a 'fast path'

With zero cross-layer shortcuts allowed, the dependency graph stays simple enough that any newcomer can trace a request's path through the codebase without exceptions to memorize. The cost is an extra hop of latency on every request — a trade this pattern makes deliberately in favor of comprehensibility.

02

One deployable unit

ChoseA monolithic layered application
OverSplit each layer into its own deployable service (microservices)

For a team of 1-2 groups, one deploy unit means one CI pipeline, one release process, and no network calls between layers to secure or version. Microservices would buy independent scaling per layer, but this system doesn't yet have a layer whose load justifies that operational cost.

03

Persistence Layer as the only SQL-aware code

ChoseA dedicated Persistence Layer owns all database access
OverLet the Business Logic Layer issue queries directly

Isolating every query behind one layer means a database or ORM swap touches exactly one place in the codebase, and it confines the entire SQL-injection attack surface to code that is reviewed and tested specifically for it.

04

Presentation Layer stays logic-free

ChoseThe UI only translates input and output — no business rules live here
OverDuplicate validation in both the UI and the Business Logic Layer for snappier feedback

A single source of truth for business rules avoids the two copies drifting apart. When a second UI (mobile) is added later, it inherits the exact same enforced rules for free instead of re-implementing them.

//What Breaks First

Bottlenecks & Failure Modes

Reading a system means sensing where it cracks under 10× load. These are the pressure points of this design, and how it holds.

Risk 01

Every request pays for all four hops

Failure mode

Even a trivial read crosses Presentation, API, Business Logic, and Persistence before it ever reaches the Database. Under high load that fixed overhead adds up across every single request, not just the expensive ones.

Mitigation

This pattern alone doesn't solve it — it pairs well with introducing a cache in front of Persistence, or evolving toward a read-optimized pattern like CQRS once the overhead genuinely matters.

Risk 02

The whole application scales as one unit

Failure mode

If only the Persistence Layer is under load, the entire monolith still has to be scaled (redeployed, given more instances) to handle it — wasting resources on the other four layers that were never the bottleneck.

Mitigation

This is the fundamental trade of layered versus microservice architectures. Extracting the hot layer into its own independently scalable service is the usual next step once it becomes a genuine, measured bottleneck.

Risk 03

Anemic pass-through layers

Failure mode

Over time, a layer can degenerate into 'call the layer below, do nothing else' boilerplate — providing the structure of layering without enforcing any real rule or translation.

Mitigation

Only keep a layer if it enforces something real. Collapse a layer that has become a pure pass-through rather than preserving it out of habit.

Risk 04

A single database is the ultimate bottleneck

Failure mode

Because every layer eventually funnels into one Database, that database's throughput caps the whole system's throughput no matter how much the upper layers are scaled.

Mitigation

Read replicas and connection pooling at the Persistence Layer buy headroom; once read and write load diverge enough, evolving toward CQRS is the more structural fix.

//Active Recall

Test Yourself

If you can answer these without scrolling back up, the architecture is yours. Try each one out loud before revealing.

//Go Deeper

Further Reading

Patterns used in this design
Hexagonal ArchitectureCQRS Pattern
//A Word

From the Creator

Every great system starts as a sketch on a whiteboard. The ability to zoom out and see the whole picture (how services connect, where data flows, what breaks and why) is what separates engineers who build features from engineers who build systems. This diagram is more than boxes and arrows. It's a map of decisions, trade-offs, and intentional design.

Studying architectures isn't just about passing interviews. It's about training your intuition. The more systems you take apart, the better you get at sensing where a monolith will crack, where a queue belongs, or when a cache is hiding a deeper problem. You start seeing patterns instead of chaos.

So keep reading, keep tracing those edges, keep asking "why this way and not that way." The engineers who truly understand large systems are the ones who never stop being curious about how things fit together. That curiosity is the only ingredient that really matters.

Atharva Arbat@arbat_atharva

//Explore

More Patterns