Architecture Styles Comparison

For navigation and high-level descriptions of each style, see Architecture Styles.

Ratings are qualitative (★☆☆☆☆ to ★★★★★) based on Richards & Ford's scorecards in Fundamentals Of Software Architecture, Ch 10–17. These reflect the inherent tendencies of each style — individual implementations can deviate based on design choices.

At-a-Glance Ratings

Key Dimensions

Monolith vs Distributed

Monolithic styles (single deployment unit, single quantum):

• Layered Architecture — technical partition, simplest
• Pipeline Architecture — technical partition, ETL-oriented
• Microkernel Architecture — domain partition, customisability-focused

Distributed styles (multiple deployment units, multiple quanta possible):

• Service Based Architecture — 4–12 coarse domain services; pragmatic
• Event Driven Architecture — async event-driven; highest elasticity/scalability
• Space Based Architecture — in-memory grid; extreme performance
• Soa Architecture — orchestration-driven; legacy enterprise pattern
• Microservices Architecture — fine-grained; maximum agility

Technical vs Domain Partitioning

(See Technical Vs Domain Partitioning)

Architecture Quanta Count

Decision Guide

Start here: how many differing sets of architecture characteristics does the system need?

• One set → monolith is viable. Choose based on domain needs:

  • Simplest possible, budget-constrained → Layered Architecture
  • Data transformation / ETL → Pipeline Architecture
  • Customisation is the core use case → Microkernel Architecture

• Multiple sets (different scalability, availability, etc. for different parts) → distributed:

  • Team lacks DevOps maturity or needs ACID transactions → Service Based Architecture
  • Highest scalability/elasticity, async workloads → Event Driven Architecture
  • Extreme performance, in-memory required → Space Based Architecture
  • Maximum agility, large teams, mature DevOps → Microservices Architecture
  • SOA → avoid for new systems; used to understand legacy

Secondary decision: synchronous vs asynchronous communication?

"Use synchronous by default, asynchronous when necessary." (→ Fundamentals Of Software Architecture)

Async is required when: scalability/elasticity are primary concerns, workflows are long-running, or differing service throughput would cause synchronous timeout/coupling problems.

The 8 Fallacies of Distributed Computing

Any distributed style pays the costs captured in the Fallacies Of Distributed Computing (Deutsch, Sun Microsystems, 1994): the network is not reliable, not zero-latency, not infinite-bandwidth, not secure, not static in topology, not administered by one person, not free to use, and not homogeneous. Architects choosing distributed styles must design explicitly for each fallacy.

Stamp Coupling (Distributed Styles Only)

Stamp coupling — passing more data than needed across service boundaries — wastes bandwidth and creates implicit schema coupling. Mitigate with: field selectors, GraphQL, purpose-specific request/response schemas.

Style Evolution Paths

Common migration trajectories:

• Layered → Service-Based (split into 4–12 domain services; keep shared DB initially)
• Service-Based → Microservices (split databases; increase granularity; add DevOps automation)
• Layered → Modular Monolith (add domain partitioning within a single deployment; preserve migration option)

Open Questions

Open question: How do Richards & Ford's ratings compare to Kleppmann's implicit treatment in DDIA? The overlap is primarily in the distributed styles (event-driven, service-based, microservices) and their consistency/transaction trade-offs.

Finding: Software Architecture The Hard Parts substantially extends this taxonomy. Ch 4 introduces six decomposition patterns for breaking apart a monolith, with service-based architecture as the primary migration destination. Ch 6 adds data decomposition — the five-step process for separating a shared database across services. The key SATH contribution: concrete, step-by-step guidance on how to decompose, not just when.