Architecture Patterns

System architecture patterns provide proven templates for structuring applications and aligning software design with organisational scaling goals. Choosing the right pattern requires balancing development speed, system complexity, and organisational structure.

Here is a high-level overview of key architectural patterns used in modern software design:

1. Micro Frontends

Extends the concept of microservices to frontend development. The user interface is split into independent, domain-owned applications that are composed at runtime or compile-time.

• Trade-offs: Enables independent team deployments and technology stack agility, but increases orchestration complexity and can impact performance (bundle sizes) and UX consistency.
• Resources:
  • Martin Fowler on Micro Frontends (External)
  • Micro Frontends Community Portal (External)
  • Design Systems (Internal)

2. Strangler Fig Application

An incremental migration strategy where a legacy monolithic system is gradually replaced by routing specific API paths or frontend routes to new modern services, eventually deprecating the legacy system entirely.

• Trade-offs: Minimises migration risk by avoiding "big bang" rewrites and delivers business value continuously, but introduces routing/proxy complexity and data synchronization overhead.
• Resources:
  • Strangler Fig Application (Martin Fowler) (External)

3. Command Query Responsibility Segregation (CQRS)

Separates write operations (commands) from read operations (queries) into distinct data models, allowing each side to scale and optimise independently.

• Trade-offs: Optimises read/write performance and simplifies domain logic on the write side, but introduces eventual consistency challenges and increased infrastructure complexity.
• Resources:
  • CQRS Architecture (Internal)
  • CAP Theorem (Internal)

4. Microservices

Decomposes an application into a collection of small, loosely coupled services organised around business domains. Each service is fully autonomous and communicates via lightweight APIs.

• Trade-offs: Strong team autonomy, independent scaling, and high deployment frequency, but introduces operational complexity, distributed tracing challenges, and network latency.
• Resources:
  • Conway's Law (Internal)
  • Architectural Decision Records (Internal)

5. Transactional Outbox

Reliably publishes event notifications in distributed systems. Instead of directly publishing an event to a message broker during a database transaction (which risks inconsistent states if one fails), the event is saved to an "Outbox" table in the same database within the local transaction. A separate relay process reads from this table and publishes the events asynchronously to the message broker.

• Trade-offs: Guarantees at-least-once message delivery and resolves the dual-write problem, but introduces latency in message propagation and database polling/log-tailing overhead.
• Resources:
  • Transactional Outbox (Microservices.io) (External)
  • CQRS Architecture (Internal)
  • Event-Driven Architecture (Internal)

Explore Next

• Event-Driven Architecture — A guide on asynchronous events, team decoupling, and event standards like CloudEvents.

References

• Cloud Design Patterns (Microsoft Azure) — A comprehensive catalogue of cloud architecture design patterns and implementation guidelines.