Layered (N-tier) Architecture
Explore the layered architecture pattern to understand how systems are organized into stacked horizontal layers with distinct responsibilities. Learn the structure, common layers like presentation, business logic, and data access, benefits such as simplicity and testability, as well as drawbacks like monolithic deployment. This lesson helps you decide when to use layered architecture and how it fits within broader system design patterns.
The previous lesson explored how microservices decompose systems along domain boundaries. That decomposition is powerful when independent scaling and team autonomy are genuine requirements. But not every system needs domain-based separation. Some systems benefit more from vertical separation of concerns, where code is organized by technical responsibility rather than business domain. This is the foundation of layered (N-tier) architecture, a pattern that organizes a system into stacked horizontal layers, each with a distinct responsibility, where each layer communicates only with the layer directly below it.
This lesson covers the structure of layered architecture, the responsibilities of common layers, the benefits and drawbacks of this approach, and real-world systems where it excels.
Structure and purpose of layered architecture
Layered architecture is a monolithic or modular design where code is organized into horizontal tiers, each encapsulating a specific concern such as presentation, business logic, or data access. Think of it like floors in a building: each floor has a defined purpose, and you access them in order rather than jumping randomly between them.
The core structural rule is strict layering. A layer may only call the layer immediately below it, never skipping layers. When the presentation layer needs data, it calls the business logic layer, which in turn calls the data access layer. This creates a predictable, top-down dependency graph that simplifies reasoning about the system.
An alternative approach,