Architecture patterns

Teams reach for architecture patterns because the big structural questions have been answered many times before. Knowing the catalog turns “how should we build this?” into “which trade-offs do we accept?”, which is a far easier conversation to have in a design review.

Why do architecture patterns matter?

• Shared vocabulary. Saying “event-driven with a saga for order fulfillment” tells another engineer the shape of the system in one sentence.
• Known trade-offs. Each pattern comes with a list of what it makes easy and what it makes hard, learned by other teams at their expense.
• Faster reviews. Reviewers can check a design against the pattern’s known failure modes instead of reasoning from scratch.
• Honest comparison. Putting two patterns side by side forces the team to name the quality attributes it cares about, which is the heart of system design.

What are the most common architecture patterns?

Pattern	What it solves	What it costs
Layered	Keeps presentation, business logic and data access from tangling	Changes often touch every layer, and layers can become pass-through
Client-server	Many users sharing one source of truth	The server is a single point of scale and failure
Three-tier	Scaling and securing logic separately from data	Extra network hops and more infrastructure to run
Monolithic	One deployable that is simple to build, test and debug	Everything scales and ships together, and boundaries erode
Microservices	Teams deploying and scaling independently	Distributed failures, data consistency and far more operations work
Event-driven	Loose coupling and absorbing bursts of work	Hard to trace a request, and eventual consistency everywhere
Pipe and filter	Processing data through independent, reusable steps	Poor fit for interactive work, and overhead at every step
Microkernel	A stable core extended by plug-ins	The core’s interfaces are hard to change once plug-ins exist
Space-based	Very high load without a database bottleneck	Complex in-memory data grids and expensive to reason about
Serverless	Paying only for what runs, with no servers to manage	Cold starts, vendor lock-in and limits on long-running work
MVC	Separating a user interface from data and rules	Only covers the application, not how it is deployed

The rows link to the patterns that have their own glossary page. The thumbnails at the top of this page show the shape of eight of them.

How do you choose an architecture pattern?

1. Name the quality attributes that matter. Pick the top three from scalability, availability, deployability, testability, performance, security and cost. A pattern that is great at the wrong three is the wrong pattern.
2. Look at the team. Microservices need a team per service and mature operations. A single small team ships faster with a monolith.
3. Look at the rate of change. Parts of the system that change at different speeds, or are owned by different teams, are candidates for a boundary.
4. Look at the data. If every feature needs the same transactional data, a pattern that splits that data across services will fight you.
5. Draw two candidates. An architecture diagram of each makes the trade-offs concrete. A C4 container diagram is a good level for the comparison.
6. Record the decision. Write an architecture decision record with the options considered and the reasons, so the choice can be revisited when the facts change.

How do patterns combine?

Patterns apply at different levels, and a complete system architecture stacks several of them. At the deployment level a system might be three-tier, with an API gateway in front. Inside the application tier it might be a set of microservices that communicate through events. Inside each service the code is layered, and the web-facing service uses MVC. A scheduled report runs as a serverless function.

The combinations that cause trouble are the ones that pull in opposite directions. Microservices that all share one database have the cost of distribution without the independence. An event-driven system in which every consumer calls back synchronously to the producer is a monolith with extra steps.

What are common architecture pattern mistakes?

• Choosing by fashion. Microservices because a conference talk said so, not because the team needs independent deployment.
• Ignoring the operational cost. Every pattern that adds boundaries adds monitoring, deployment and debugging work. Budget for it.
• Applying one pattern everywhere. The checkout flow and the nightly report rarely need the same structure.
• Drifting silently. A layered system where every layer calls every other has stopped being layered. Keep the architecture diagram current so drift is visible.
• Skipping the record. Without a written decision, the next team rediscovers the trade-offs the hard way.

How do architecture patterns differ from design patterns?

Architecture patterns operate on the system: services, tiers, queues and the boundaries between teams. Design patterns operate on the code inside one component: how objects are created, composed and notified. The observer pattern inside a service and an event-driven architecture across services are the same idea at two scales, which is why the vocabulary is shared. In the C4 model, architecture patterns show up at the container level and design patterns at the component and code levels.

How do you document an architecture pattern?

• Pattern catalogs and books. Published references such as Fowler’s and Richards’s catalogs describe each pattern with its context, forces and consequences, and are the place to check a pattern’s known problems.
• Architecture decision records. The lightest way to document which pattern a system uses and why. One record per decision, kept with the code.
• AI diagramming tools. Tools like Eraser turn a description of a system in any of these patterns into an architecture diagram you can keep editing, so the diagram of each candidate costs minutes rather than an afternoon.

For more on this kind of diagram, see architecture diagrams.

Frequently asked questions