Architectural Patterns

Patterns as Reusable Decisions

An architectural pattern is a proven structural arrangement for organizing a software system. It is not a library or a framework. It is a set of decisions about how components are arranged, how they communicate, and where responsibilities live. Choosing a pattern means choosing which tradeoffs you accept.

This session surveys five major patterns. Each one solves a different class of problem. Most real production systems combine two or more of them.

Multi-Tier Architecture

Multi-tier (often called n-tier) separates the system into horizontal layers, each handling a distinct concern. The classic version has three tiers: presentation, business logic, and data. Each tier communicates only with its immediate neighbor.

This pattern works because separation of concerns reduces cognitive load. Frontend developers work in the presentation tier without touching database queries. Backend developers implement business rules without worrying about HTML rendering. Database administrators optimize storage without breaking application logic.

The limitation is rigidity. Every request must traverse all tiers, even when only one tier does meaningful work. Adding a new feature often requires changes in every layer. And horizontal scaling is uneven: the data tier typically becomes the bottleneck while the presentation tier sits idle.

Event-Driven Architecture

Event-driven architecture (EDA) structures the system around the production, detection, and reaction to events. Instead of components calling each other directly, they emit events. Other components subscribe to the events they care about and react independently.

In this example, the order service publishes an "Order Placed" event. Four services react to it independently. The order service does not know or care how many consumers exist. Adding a fifth consumer (say, a fraud detection service) requires zero changes to the producer.

EDA comes in two topologies, as described in Mark Richards' Software Architecture Patterns:

• Broker topology: Events flow through a lightweight message broker. No central orchestrator. Each consumer decides what to do with each event. Good for simple, decoupled flows.
• Mediator topology: A central mediator receives events and orchestrates a sequence of steps across consumers. Good for complex workflows that require ordering and error handling.

The strength of EDA is loose coupling and extensibility. The weakness is that the overall flow of the system becomes harder to trace. When something goes wrong, you cannot follow a single stack trace. You follow events through a broker, across services, through time.

Microservices Architecture

Session 1.5 covered this in detail. As an architectural pattern, microservices decompose the system vertically by business capability rather than horizontally by technical layer. Each service owns its own data, logic, and interface for a specific domain.

The pattern's defining characteristic is independent deployability. If a service can only be deployed alongside other services, it is not a microservice. It is a distributed monolith, which inherits the costs of both architectures and the benefits of neither.

Microservices are often combined with event-driven architecture. Services communicate through events rather than direct API calls, which further reduces coupling and improves resilience.

Cell-Based Architecture

Cell-based architecture, documented in detail by WSO2's reference architecture, organizes the system into self-contained cells. Each cell is a complete unit that includes its own services, data stores, and communication gateway. Cells interact with each other through well-defined, versioned APIs at the cell boundary.

The cell boundary acts as a blast radius. If everything inside Cell A fails, Cell B is unaffected because it communicates only through the cell gateway, which can implement circuit breakers, retries, and fallbacks.

This pattern is particularly useful for very large systems where even microservices become hard to manage. Instead of managing 300 individual services, you manage 20 cells, each containing 10-20 services. The cell provides an intermediate level of organization between individual services and the overall system.

Serverless Architecture

Serverless architecture delegates all infrastructure management to a cloud provider. You write functions that execute in response to events (HTTP requests, message queue entries, file uploads, timers). The provider handles provisioning, scaling, and deprovisioning.

Serverless excels at variable, unpredictable workloads. An image processing function that runs 10 times on Monday and 10,000 times on Friday costs proportionally. There is no idle capacity to pay for. The operational burden approaches zero for small to medium workloads.

The constraints are real. Functions have execution time limits (15 minutes on AWS Lambda). Cold starts add latency when a function has not been invoked recently. State must be stored externally. Vendor lock-in is significant because your function code is deeply coupled to the provider's event model, IAM system, and supporting services.

Pattern Comparison

Combining Patterns

Production systems rarely use a single pattern in isolation. A typical e-commerce platform might use multi-tier for its web frontend, microservices for its backend capabilities, event-driven communication between those services, and serverless for image resizing and email sending. The patterns are not competing alternatives. They are complementary tools applied at different levels of the system.

The question is not "which pattern should we use?" It is "which pattern fits this specific part of the system, given our team size, operational maturity, and the constraints of the problem?"

Systems Thinking Lens

Each pattern creates a different feedback structure. Multi-tier creates long feedback loops (changes ripple through all layers). Event-driven creates many short, independent loops (each consumer reacts on its own). Microservices create team-level loops (each team iterates independently). Cell-based creates nested loops (within cells and between cells).

The pattern you choose determines where delays accumulate, where failures propagate, and where teams can move independently. These are structural decisions with compounding effects over months and years. A pattern that feels efficient today can create organizational gridlock in two years if the feedback loops it creates do not match how your teams actually work.

Further Reading

• Mark Richards, Software Architecture Patterns, Chapter 2: Event-Driven Architecture (O'Reilly). Clear explanation of broker and mediator topologies with practical examples.
• WSO2, Cell-Based Reference Architecture (GitHub). The foundational document describing cell-based architecture, its principles, and implementation guidance.
• Microsoft, Event-Driven Architecture Style (Azure Architecture Center). Practical guidance on implementing event-driven systems with cloud services.
• AWS, Serverless Architectures with AWS Lambda (AWS Whitepaper). Comprehensive guide to serverless patterns, anti-patterns, and operational considerations.
• Martin Fowler, "Microservice Trade-Offs" (martinfowler.com). Balanced discussion of what microservices cost versus what they provide.