Software Architecture Patterns: How to Choose the Right One

Software architecture patterns are named, reusable structures for organizing a system, and the right one depends on the constraint that hurts most today. A team that ships weekly needs a different structure than a team that must survive a traffic spike.

This guide compares seven software architecture patterns and gives a table for choosing between them when you plan custom software development.

What are software architecture patterns?

A software architecture pattern is a reusable solution to a recurring structural problem in a system. Each pattern fixes a set of components and the way they connect, and each works well in some situations and badly in others.

Mark Richards’ Software Architecture Patterns (O’Reilly, second edition, July 2022) describes each pattern by how it works and when to use or avoid it, including its benefits and drawbacks. In our judgment, architectural patterns in software engineering also give a team a shared vocabulary, so “this is event-driven” tells everyone how the system is divided.

A pattern is one piece of a wider field, and our software architecture guide covers the definitions, styles and documentation around it.

What is the difference between an architectural pattern and a design pattern?

An architectural pattern shapes the whole system, while a design pattern shapes the code inside one component. Layered architecture decides how an application divides into tiers. A design pattern decides how one class inside a tier is built.

Software architecture and design patterns blur at the edges. Richards’ second edition adds a discussion of architecture patterns versus styles, and the Azure Architecture Center uses “architecture style” for the same system-level shapes. In our reading, “style” and “pattern” are near-synonyms at the system level, and “design pattern” is the code-level term.

Martin Fowler’s Patterns of Enterprise Application Architecture (2002) catalogs about 40 patterns for structuring enterprise applications. In our judgment, it sits between the two levels. For the wider split, see our post on software architecture vs software design.

What are the main types of software architecture patterns?

Richards’ 2015 report covers five architectural patterns: layered, microkernel, event-driven, microservices, and space-based. This guide adds hexagonal architecture and pipes and filters, which solve different problems. Ratings and weaknesses below come from Richards’ August 15, 2015 excerpt and from the Azure Architecture Center’s styles page, updated October 14, 2025.

1. Layered architecture

Layered architecture splits an application into horizontal layers, such as presentation, business, persistence, and database, where each layer calls only the layer beneath it.

• Use it when you need a default starting point, since Richards calls layered a solid general-purpose pattern and a good starting point for most applications, or when you are migrating an existing layered application, and avoid it when updates are frequent.
• Cost: Richards’ excerpt rates overall agility low, because changes are cumbersome and time-consuming, and deployments tend toward a single unit.

If fast, frequent change is your top need, compare layered with microservices before you commit, which is TekRevol’s judgment.

2. Microkernel architecture

Microkernel architecture, also called plug-in architecture, keeps minimal functionality in a core system and adds features as independent plug-in modules that connect through a registry.

• Use it when you ship a product in versions and add features over time, or when a business system has many variable rules, such as insurance claims with state-specific rules, and avoid it when you need high scalability.
• Cost: Richards’ excerpt rates scalability low because most implementations are product-based and generally smaller in size, and rates ease of development low because the pattern requires thoughtful design and contract governance.

3. Event-driven architecture

Event-driven architecture lets producers emit events that consumers react to in near real time, with a broker or mediator handling communication.

• Use it when you need low-latency processing, such as IoT, or very high-volume streaming data, and avoid it when business transactions require strong consistency across services.
• Cost: the team must handle guaranteed delivery, event ordering, eventual consistency, and duplicate messages, and Richards’ excerpt rates the style as complex to develop and test.

4. Microservices architecture

Microservices architecture breaks an application into small, autonomous services, each implementing one business capability and owning its own data.

• Use it when the domain is complex and changes often, and avoid it when your development and DevOps practices are still immature.
• Cost: service discovery, data consistency, distributed-system management, and inter-service latency all add complexity.

For a mobile backend, our guide on microservices patterns for mobile apps goes deeper.

5. Space-based architecture

Space-based architecture keeps application data replicated in in-memory grids instead of a central database, and its processing units scale up or down with load.

• Use it when user load is variable or unpredictable in a smaller web application, such as a bidding or auction site, and avoid it when the application depends on a large relational database with heavy operational data.
• Cost: it is complex and expensive to implement, and Richards’ excerpt rates testability low because simulating high user loads is costly.

6. Hexagonal architecture

Hexagonal architecture, published by Alistair Cockburn on September 4, 2005, puts the application core in the middle and connects it to the outside world through ports, each with swappable adapters.

• Use it when users, programs, automated tests, and batch scripts must all drive the same core logic, and avoid it when the application is a thin layer with little logic.
• Cost (our judgment, as is the avoid-it condition): you write an adapter for every technology a port touches.

7. Pipes and filters

Pipes and filters break a complex task into independent, reusable filters that each do one job, connected by pipes that pass each output to the next filter.

• Use it when processing splits into independent steps with different scaling needs, and avoid it when the work is request-response, or the steps must share one transaction.
• Cost: the Azure Architecture Center says the pattern is usually implemented as a monolithic pipeline, so changes need end-to-end testing, although filters can be deployed separately.

How do you choose a software architecture pattern?

Choose the pattern that fixes the constraint hurting most today, and pick the simplest one that does. That rule is our judgment, not a published standard. The TekRevol Pattern Fit Table below maps common situations to a pattern and its main cost.

The table itself is TekRevol’s judgment. Costs that have a source come from Richards’ August 15, 2015 excerpt or the Azure Architecture Center, not from the second edition (July 2022).

For a startup with one team and an unproven product, our judgment is to begin with a single layered application and move to another pattern only when a constraint appears. Microservices add distributed-system costs before the product needs them.

Treat the table as a starting point, because the right answer also depends on your team’s skills and budget, and on the software architecture principles your team has agreed to follow. For a related view on startups, see our guide to solid architecture for startups that scale.

Which supporting patterns pair with each main pattern?

In our judgment, main patterns rarely work alone, so teams add smaller supporting patterns, such as those in the Azure Architecture Center’s patterns catalog. The pairings below are our judgment, not a published mapping.

These pairings matter most in distributed systems, the setting for cloud-native development. Keep each pairing explicit, so every part of the system follows one pattern.

What mistakes do teams make with architecture patterns?

In our judgment, the first mistake is choosing a pattern because it is popular instead of because it fits a constraint. On a small product with one team, microservices add the complexity Azure describes, such as service discovery and data consistency, with little of the autonomy benefit.

The second mistake is building a layered system where requests only pass through. Richards calls this the architecture sinkhole: requests move through layers that add little or no logic. His excerpt suggests a rough 80-20 guideline, and if most requests are pass-through, consider making some layers open.

How can TekRevol help you choose a software architecture pattern?

TekRevol is a software development company that helps you map your constraints to the right pattern. Our custom software development process includes architecture planning in the design stage.

Come with the constraint that hurts most, such as slow releases, a traffic spike, a legacy system, or weak test coverage. Match it against the TekRevol Pattern Fit Table in this guide, and ask for a written decision that names the pattern and the cost you accept.

If you already run a monolith, the same conversation can test whether a supporting pattern, such as the strangler fig, lets you move in steps instead of rewriting everything at once.

Start with a Free Consultation.