7 Software Architecture Patterns: Examples and Diagrams (2026)

A software architecture pattern is a general, reusable solution to a recurring organizational problem in software design. Patterns describe how to structure a system's components, how they communicate, and how they handle cross-cutting concerns like scalability, reliability, and deployment. Choosing the right pattern upfront determines how easy (or painful) it will be to scale, debug, and extend your system years later.

This guide covers the seven architecture patterns you'll encounter most often in production systems, with a diagram prompt for each so you can visualize your own system in seconds.

1. Layered (N-Tier) Architecture

What it is: Components are organized into horizontal layers — typically Presentation, Business Logic, Data Access, and Database — where each layer only communicates with the layer directly below it.

When to use it: CRUD applications, internal tools, monoliths that need clear separation of concerns, and teams with clear frontend/backend/data roles. The most common architecture pattern in enterprise software.

Trade-offs: Simple to understand and test in isolation. Tends to accumulate "god objects" in the business layer over time. Changes that span multiple layers require changes in every layer. Scales vertically but not horizontally as easily as microservices.

2. Microservices Architecture

What it is: The application is decomposed into small, independently deployable services, each responsible for a specific business capability and owning its own data store.

When to use it: Large teams that need to deploy independently, systems with parts that need to scale differently (the checkout service at peak vs. the reporting service), and organizations with clear domain boundaries.

Trade-offs: Excellent team autonomy and independent scaling. High operational complexity: distributed tracing, service discovery, inter-service authentication, and schema management become necessary. Network failures and latency must be designed for explicitly. The most common microservice architecture mistakes involve premature decomposition — breaking up a system that isn't ready for the operational overhead.

3. Event-Driven Architecture

What it is: Components communicate by producing and consuming events via a message broker (Kafka, RabbitMQ, SQS). Services are decoupled — producers don't know who consumes their events, and consumers don't know who produced them.

When to use it: Systems with high write throughput (IoT data ingestion, activity streams), workflows with many downstream side effects from a single trigger (order placed → inventory decrement + shipping + email + analytics), and any architecture where tight coupling between services creates a scaling bottleneck.

Trade-offs: Excellent scalability and decoupling. Hard to trace end-to-end transactions (requires distributed tracing). Eventual consistency is the norm — if your business domain requires strong consistency, event-driven adds complexity. Debugging requires good observability tooling.

4. Serverless Architecture

What it is: Application logic runs in stateless, short-lived functions (AWS Lambda, Google Cloud Functions, Azure Functions) triggered by events (HTTP requests, queue messages, scheduled tasks). The cloud provider manages all infrastructure.

When to use it: Workloads with variable or unpredictable traffic (scales to zero when idle, scales to thousands of instances instantly), background jobs, data processing pipelines, and APIs where operational simplicity outweighs the cost of cold starts.

Trade-offs: Zero infrastructure management, automatic scaling, pay-per-invocation billing. Cold starts add latency (50–500ms) on the first invocation. Functions are stateless — session state must be externalized to Redis, DynamoDB, or S3. Vendor lock-in is high (Lambda code is portable; Lambda event sources are not).

5. CQRS (Command Query Responsibility Segregation)

What it is: Read and write operations are handled by separate models. Commands (writes) go through a write model that enforces business rules and emits events. Queries (reads) are served by a separate read model optimized for the specific query pattern.

When to use it: Systems where read and write workloads have very different performance characteristics, where you need multiple read models optimized for different query types (OLTP for transactional reads, Elasticsearch for full-text search, Redis for session data), or where you need an audit log of every state change.

Trade-offs: Excellent scalability and read performance — each read model is purpose-built. Eventual consistency between write and read models means reads may lag behind writes (typically milliseconds to seconds). Significantly more complex than a simple CRUD model. Often paired with Event Sourcing where the event log is the write model.

6. Hexagonal Architecture (Ports and Adapters)

What it is: The application core (domain logic) is surrounded by ports (interfaces) and adapters (implementations). External concerns — HTTP, databases, message queues, third-party APIs — connect through adapters without the core knowing or caring what's on the other side.

When to use it: Applications where the domain logic is complex and must be testable in isolation, systems that need to support multiple delivery mechanisms (REST API + gRPC + CLI + message queue), and architectures where you expect to swap infrastructure (e.g., migrate from PostgreSQL to DynamoDB) without rewriting business logic.

Trade-offs: Domain logic is highly testable and completely decoupled from infrastructure. Adds abstraction layers (ports/adapters) that developers must understand. Can feel like over-engineering for simple CRUD applications. Works extremely well when combined with Domain-Driven Design (DDD).

7. Service Mesh Architecture

What it is: In a microservices deployment (typically Kubernetes), a sidecar proxy (Envoy) is injected alongside every service. The mesh of sidecars handles cross-cutting concerns — load balancing, circuit breaking, retries, mTLS encryption, distributed tracing — without any code changes to the services themselves.

When to use it: Kubernetes-based microservices deployments that need: zero-trust mTLS between services without per-service TLS code, fine-grained traffic management (canary releases, A/B testing, traffic mirroring), and automatic distributed tracing across all services. The major service meshes are Istio, Linkerd, and Cilium.

Trade-offs: Standardized, automated handling of the hardest parts of microservices (security, observability, reliability). High operational complexity — the mesh itself becomes a critical infrastructure component. Adds latency (Envoy sidecar adds ~1ms per hop). Overkill for small-scale deployments; essential at large scale.

How to choose the right architecture pattern

No architecture pattern is universally correct. The right choice depends on your team size, deployment frequency, domain complexity, and operational maturity.

• Small team, early product — start with layered architecture or a well-structured monolith. You can migrate to microservices when team size and deployment friction make it necessary.
• High write throughput, many downstream effects — event-driven architecture is likely the right fit. Kafka or SQS decouples your producers from consumers and handles bursts.
• Complex domain logic, need for testability — hexagonal architecture keeps your domain pure and swappable, regardless of whether you deploy as a monolith or microservices.
• Read-heavy with diverse query patterns — CQRS lets you optimize read models for each access pattern without compromising write consistency.
• Kubernetes at scale, many services — a service mesh standardizes security and observability across the board without per-service implementation work.
• Spiky or unpredictable traffic — serverless eliminates the cost of idle infrastructure and scales to zero automatically.

Frequently asked questions

What is the most common software architecture pattern?

Layered (N-tier) architecture is the most common pattern in production software. Most enterprise applications, CRMs, ERPs, and internal tools are built with a presentation layer, business logic layer, and data layer. Microservices have grown rapidly in popularity but layered architecture remains the dominant pattern by number of deployed systems.

What is the difference between microservices and event-driven architecture?

These are orthogonal concepts that are often combined. Microservices is about how you decompose a system (into small, independent services). Event-driven architecture is about how those services communicate (asynchronously via events rather than synchronous HTTP calls). A microservices system can use synchronous REST calls, asynchronous events, or both.

When should you NOT use microservices?

Avoid microservices when: your team has fewer than 5–8 engineers (the operational overhead exceeds the coordination savings), your domain boundaries are unclear (premature decomposition leads to the wrong service cuts), or you don't have mature CI/CD and observability tooling (microservices require both to be manageable).

What is the difference between CQRS and event sourcing?

CQRS separates read and write models. Event sourcing stores state as a sequence of events rather than the current state. They're often used together — event sourcing provides an event log as the write model, and CQRS uses projections from that log to build read models — but each can be used independently.

Try it

Use any of the prompts above in ArchitectureDiagram.ai to generate a diagram for your system. See also: microservice architecture patterns in depth, event-driven architecture examples, documenting with the C4 model, more AI diagram prompts.