⌘ The Architecture Reference

Sty choosing · Architecture Styles · Intermediate

Comparing the Styles

The consolidated scorecard — every style rated across partitioning, cost, simplicity, scalability, fault tolerance, performance, and more — and how to read it for trade-offs.

Sty choosing Intermediate ⏱ 4 min read Complete

🧭 Analogy

This is the spec sheet you compare before buying. Just as you’d lay out cars by price, mileage, cargo, and safety to spot the one that fits your life, the consolidated matrix lets you scan one characteristic — say scalability — straight down every style and see instantly who wins and who pays for it.

The consolidated scorecard

The book closes with a single matrix so an architect can scan a characteristic across all styles at a glance. Ratings are 1 (poorly supported) to 5 (excellently supported); cost is in dollar signs ($ cheapest to $$$$$ most expensive); partitioning is T (technical), D (domain), or D/T (either).

CharacteristicLayeredMicrokernelEvent-drivenMicroservicesSpace-based
PartitioningTD/TTDT
Overall cost$$$$$$$$$$$$$$$
Agility13352
Simplicity54111
Scalability11555
Fault tolerance11553
Performance33525
Extensibility13553

Service-based (covered in Service-based architecture) and pipeline (in Pipeline architecture) round out the landscape: service-based sits between the monoliths and microservices with many 4-star ratings and the best ACID support among distributed styles; pipeline tracks layered with slightly better modularity.

graph LR
subgraph Monolithic["Monolithic: win simplicity + cost"]
  L["Layered<br/>simple, cheap"]
  M["Microkernel<br/>extensible"]
end
subgraph Distributed["Distributed: win scalability + fault tolerance"]
  E["Event-driven<br/>balanced"]
  MS["Microservices<br/>agile, costly"]
  SB["Space-based<br/>extreme scale"]
end
Monolithic -->|"pay: scalability,<br/>fault tolerance"| Distributed
Distributed -->|"pay: simplicity,<br/>cost"| Monolithic
quadrantChart
title Simplicity vs scalability
x-axis Low scalability --> High scalability
y-axis Low simplicity --> High simplicity
quadrant-1 Scales and simple
quadrant-2 Simple, limited scale
quadrant-3 Hard and limited
quadrant-4 Scales, complex
Layered: [0.15, 0.9]
Microkernel: [0.2, 0.78]
Event-driven: [0.85, 0.18]
Microservices: [0.88, 0.12]
Space-based: [0.92, 0.15]

Reading the matrix — the key trade-offs

  • Monolithic styles (layered, microkernel) win on simplicity (5 and 4) and cost ($), but lose on scalability and fault tolerance (both 1). The right default for simple systems and tight budgets.
  • Distributed styles (event-driven, microservices, space-based) all score 5 on scalability, paying with simplicity = 1 and higher cost. Choose them when operational characteristics dominate.
  • Microservices is the agility and extensibility champion (both 5) with 5/5 scalability and fault tolerance — but the most expensive ($$$$$) and the weakest on performance (2) among distributed styles, due to remote-communication latency.
  • Event-driven is the most balanced distributed style — 5s in scalability, fault tolerance, performance, and extensibility — at a moderate cost ($$$), though its simplicity is the lowest and it demands eventual consistency.
  • Space-based uniquely pairs top scalability (5) and performance (5) for extreme/elastic load, at high cost, low agility (2), and the constraint that all transactional data fit in memory.
  • Microkernel is the most extensible monolithic option (3) and the only style that can be technical or domain partitioned.

Two worked reads

The book demonstrates: if your primary concern is scalability, the matrix points to event-driven, microservices, and space-based. If you pick layered, the matrix flags deployment, performance, and scalability as your risk areas to manage.

The matrix is a guide, not a verdict

Don’t pick the style with the most 5s. The book is emphatic: this matrix is a guide. You must also weigh infrastructure support, developer skill set, project budget, deadlines, and application size — and remember that changing an architecture once it’s in place is very hard and expensive.

See also

When to use it — and when not

✅ Reach for it when

  • You want to scan one characteristic (e.g., scalability) across all styles at once.
  • You need to justify a style choice with a side-by-side comparison.
  • You are narrowing a shortlist of candidate styles before deeper analysis.

⛔ Think twice when

  • You are treating the matrix as a decision instead of a guide — it ignores skills, budget, and infrastructure.
  • You haven't yet identified which characteristics actually matter for your system.
sty-fundamentalsReading an Architecture Style

What an architecture style is, how it differs from a pattern, and how to read each style's characteristics scorecard before you commit to one.

sty-choosingChoosing an Architecture Style

The decision process — monolith vs distributed via the quantum, where data lives, sync vs async — plus worked monolith and distributed case studies.

sty-monolithicLayered Architecture

The n-tier default monolith — horizontal layers, closed-vs-open isolation, the sinkhole anti-pattern, and why it is cheap and simple but hard to scale.

sty-distributedMicroservices Architecture

The domain-partitioned distributed style built on bounded contexts — single-purpose services, distributed data, operational automation, and the agility champion that pays in performance and cost.

Check your understanding

Score: 0 / 4

1. Which styles all score 5/5 on scalability?

The three pure distributed styles in the matrix all hit 5/5 scalability — at the cost of simplicity (1/5) and higher expense.

2. Which monolithic style is the most extensible, and the only one that can be technical or domain partitioned?

Microkernel scores higher extensibility than layered and is uniquely able to be technically OR domain partitioned.

3. What is the standout trade-off of microservices on the matrix?

Microservices is the agility/extensibility champion (both 5) with 5/5 scalability and fault tolerance, but $$$$$ cost and only 2/5 performance.

4. How should the comparison matrix be used?

The book stresses the matrix is a guide; you must also weigh infrastructure, developer skills, budget, deadlines, and app size.

Comments

Sign in with GitHub to join the discussion.