Architecture styles: a working vocabulary

Architecture styles are less a set of blueprints than a shared vocabulary. When someone says "event-driven" or "CQRS" in a design review, everyone in the room should know what that choice gives you and what it will cost later. These are short definitions of seven common ones, each with the trade-offs I'd want a team to weigh.

Monolithic architecture

In a monolithic architecture, the user interface, business logic and data access layers are built into a single unit. That unit runs as one service and is usually built, deployed and scaled as one. It's straightforward to develop and deploy, but because the components are tightly coupled it's hard to separate them, which leads to scaling and maintenance problems as the system grows.

Pros

1. Easy development: one codebase and one development environment.
2. Simple, consistent data access: one codebase and usually one database, so data access is simple and consistent.
3. Simple deployment: a single deployable unit keeps the deployment pipeline simple.

Cons

1. Scaling: you scale by running more copies of the whole application, which uses more resources.
2. Coupling: interdependent components mean one failure can bring down the whole system.
3. Long builds: even a small change can mean rebuilding the whole application.

Layered (n-tier) architecture

A layered architecture splits an application into layers, typically presentation, business logic and data storage. Each layer talks to the layers next to it through well-defined interfaces. Strictly, layers are logical divisions in the code, while tiers are physical deployment boundaries, so an n-tier system runs its layers as separately deployed "tiers". The separation means changes, and in the n-tier case scaling, can be confined to one layer, at the cost of more interactions between components.

Pros

1. Separation of concerns: each layer has its own responsibility.
2. Flexibility: the modular design makes changes easier.
3. Scalability: in an n-tier deployment, each tier can be scaled separately.

Cons

1. Complexity: more layers and interactions add complexity.
2. Performance: extra layers, and especially network hops between tiers, add latency.
3. Maintenance: more moving parts need more upkeep.

Event-driven architecture

Event-driven architecture (EDA) uses events, meaning changes in state, to trigger actions between decoupled components. Components produce, consume or react to events, which lets them communicate asynchronously. It's useful for applications that need to respond quickly as things happen, but managing and tracing events is hard.

Pros

1. Responsiveness: suits systems that must react as soon as something happens.
2. Decoupling: makes later changes and extensions easier.
3. Scalability: new components can be added that simply listen for events.

Cons

1. Event sprawl: a high volume of events adds complexity.
2. Debugging: event-based flows are hard to trace and debug.
3. Consistency: keeping state consistent across services is hard.

Microkernel architecture

A microkernel architecture uses a small core system for the application's minimal functions. Everything else is built as plugins or external modules that interact with the core. It's very extensible and modular, though it can add latency and management complexity.

Pros

1. Extensibility: new features can be added as plugins.
2. Isolation: plugins can be isolated so that one failing plugin doesn't take down the system. This isn't automatic; plugins running in the same process aren't isolated by default.
3. Reuse: modules can be reused in other projects or components.

Cons

1. Complexity: interactions between plugins and the core can get complicated.
2. Performance: extra layers and interfaces can add latency.
3. Development time: building the core system and the plugins takes time.

Microservices architecture

In a microservices architecture, the application is split into a collection of loosely coupled services that can be deployed independently. Each specialised service focuses on a single business capability, and the services communicate through APIs. It offers a lot of scalability and flexibility, but it brings operational complexity and latency from the communication between services.

Pros

1. Scalability: each service can be scaled independently.
2. Flexibility: different services can use different technologies.
3. Fault isolation: a failure in one service has limited impact on the others.

Cons

1. Complexity: needs careful design and coordination.
2. Latency: communication between services adds delay.
3. Operational overhead: you need good tooling for orchestration and monitoring.

Serverless architecture

Serverless architecture takes server management off your hands, so developers can focus on functions that run in response to events such as HTTP requests or file changes. It scales well and can be cost-effective, especially for spiky or low traffic, though at steady high load it can cost more than running your own servers. The main challenges are the latency of the first invocation (cold starts) and limited control over the runtime environment.

Pros

1. Cost: you pay for execution time, which can be cheap for spiky or low workloads.
2. Automatic scaling: capacity follows the volume of incoming requests.
3. Developer focus: no server maintenance.

Cons

1. Cold starts: the first invocation of a function can be slow.
2. Limited control: less control over server configuration.
3. State management: functions are stateless, so state has to live somewhere else.

CQRS

Command Query Responsibility Segregation (CQRS) is a pattern rather than a whole-system architecture. It separates an application's reads and writes into different models, so each can be scaled and optimised independently. With separate read models, CQRS usually accepts eventual consistency by design: the challenge is making the lag between a write and the updated read model acceptable and visible to users, not achieving strong consistency. It's often paired with event sourcing, which stores every change as an event. Teams choose event sourcing for its audit history and the ability to rebuild state, not for performance.

Pros

1. Scalability: reads and writes can be scaled independently.
2. Performance: read and write models can each be optimised for their job.
3. Complexity management: separating them can simplify complicated business logic.

Cons

1. Eventual consistency: reads can lag behind writes, and the application has to handle that.
2. Complexity: it adds another layer of development and operational work.

Key takeaways

• Monolithic: simple, but hard to scale.
• Layered (n-tier): separates concerns, but adds complexity.
• Event-driven: suits systems that must react quickly, but can be hard to manage.
• Microkernel: extensible, but can have performance costs.
• Microservices: scalable, but operationally complex.
• Serverless: can be cost-effective, but has limitations.
• CQRS: lets reads and writes scale separately, but adds complexity and eventual consistency.