What Are the 7 Core Software Architecture Patterns and When to Use Them?

1. Layered Architecture

Also known as n‑tier architecture, it separates a system into distinct layers—typically presentation, business, persistence, and database—to achieve clear separation of concerns, easier maintenance, and modular development.

Context: Complex systems evolve independently and need clear modular boundaries.

Problem: Modules must be loosely coupled yet reusable, supporting portability and modification.

Solution: Divide the software into layers, each providing a cohesive set of services with a unidirectional dependency flow.

Key concepts:

Each layer has a specific role (e.g., the presentation layer handles UI).

The architecture is technical, not domain‑specific; components, not business domains, define layers.

Layers are either closed or open; a request must pass through each intermediate layer without skipping.

Weaknesses: Performance overhead due to multiple hops, higher initial cost and complexity.

Typical use: Small‑to‑medium applications or websites with limited budget and tight timelines.

2. Multi‑Layer Architecture

Extends the layered concept by grouping related layers into logical subsystems, often seen in distributed J2EE consumer sites.

Context: Distributed deployments require splitting infrastructure into multiple subsets.

Problem: How to partition the system across independent execution units connected by communication media?

Weaknesses: High upfront cost and complexity.

Use: Suitable for distributed systems.

3. Pipe‑Filter Architecture

This pattern treats a system as a series of processing stages (filters) connected by pipes that transport data streams from input to output.

Context: Many applications need to transform discrete data streams repeatedly.

Problem: Need reusable, loosely coupled components with simple, generic interactions.

Solution: Arrange filters in a pipeline; each filter performs a specific transformation.

Typical filter types: source (producer): start of the pipeline. map (transformer): converts data. reduce (tester): evaluates conditions. sink (consumer): end of the pipeline.

Weaknesses: Not ideal for highly interactive systems; parsing overhead can hurt performance and increase filter complexity.

Use cases: ETL tools, EDI processing, compilers (lexical analysis → parsing → semantic analysis → code generation).

4. Client‑Server Architecture

Clients send requests to servers, which process them and return responses. This model centralizes shared resources and services.

Context: Many distributed services need controlled access and quality of service.

Problem: How to manage shared resources while keeping them modifiable and reusable?

Solution: Separate components into clients (requestors) and servers (responders).

Weaknesses: Server can become a performance bottleneck and single point of failure; moving functionality between client and server can be costly.

Use cases: Online applications such as email, document sharing, or banking services.

5. Model‑View‑Controller (MVC)

MVC splits an application into three roles: Model (data), View (presentation), and Controller (mediator).

Model: contains application data.

View: renders data and interacts with the user.

Controller: mediates between model and view, handling state changes.

Weaknesses: Overkill for simple UIs; may not fit all UI toolkits.

Use: Common in web and mobile UI development.

6. Event‑Driven Architecture

Systems react to asynchronous events, scaling by adding event processors as demand grows.

Context: Need to handle independent, asynchronous events in a distributed system.

Problem: Build a system that can scale from small to large workloads.

Solution: Deploy independent event processors; events are queued and dispatched to appropriate handlers.

Weaknesses: Performance and error‑recovery challenges.

Use case example: An e‑commerce order workflow where OrderCreated triggers CreditReserved or CreditLimitExceeded events, and subsequent services update order status.

7. Microservices Architecture

Breaks a monolithic application into independently deployable services, each with its own API boundary and data store.

Context: Server‑based enterprise applications serving browsers and native mobile clients.

Problem: Monoliths become too large and complex for effective deployment and resource utilization.

Solution: Decompose the system into services that can be written in different languages, manage their own databases, and be owned by separate teams.

Weaknesses: Requires robust monitoring, service orchestration, and handling of failure; adds operational overhead and cost.

Use cases: Scenarios with heavy data pipelines, such as retail reporting systems where each step (collection, cleaning, aggregation, reporting) is a separate microservice.