“Fundamentals of Software Architecture” works less like a pattern catalog and more like a textbook for architecture thinking. It ties quality attributes, modularity, styles, and the architect’s role into one coherent discipline.
That becomes most useful when abstract concerns such as scalability, modifiability, and reliability need to be turned into concrete design choices. The book gives teams a clear frame for discussing module boundaries, quality metrics, and the cost of each trade-off.
In interviews and review conversations, it serves as a strong baseline for architectural maturity: which attributes actually matter, why a style fits the context, and where the main trade-offs really sit.
Practical value of this chapter
Quality attributes
Translates abstract attributes like scalability and reliability into concrete design decisions.
Style by context
Teaches choosing architecture styles by context rather than trend or familiar tooling.
Architect role
Shows the balance between technical leadership, communication, and risk management.
Interview fundamentals
Covers core architecture concepts commonly tested early in system design interviews.
Source
Book Review
Chapter based on this article
Fundamentals of Software Architecture
Authors: Mark Richards, Neal Ford
Publisher: O'Reilly Media, 2020
Length: 432 pages
Architectural characteristics, styles (Layered, Microservices, Event-Driven) and soft skills of an architect from Mark Richards and Neal Ford.
Book structure
The book is divided into three parts, each of which covers different aspects of the architect's role:
Part I: Basics
Architectural thinking, modularity, architectural characteristics and methods for measuring them.
Part II: Architecture Styles
Layered, Pipeline, Microkernel, Service-Based, Event-Driven, Space-Based, Microservices and others.
Part III: Soft Skills
Decision making, documentation, leadership, negotiation and career development as an architect.
Article
Architectural Characteristics and Trade-offs
A detailed analysis of the characteristics of the architecture and the principles of choosing compromises
Part I: Architectural Thinking
Architecture Characteristics (ilities)
Operating
Structural
Cross-functional
Key insight: The architect must select 3-5 key characteristics for the system. Trying to optimize everything leads to “generic architecture” - a mediocre solution with no obvious advantages.
Architecture and characteristics relationship
thinking
Critical for success: the architect should choose minimum characteristics, not maximum.
Modularity and connectivity
Modularity metrics
Distance from Main Sequence
Metric for assessing the quality of a module through the balance of abstraction and stability:
D = |A + I - 1|A = Abstractness, I = Instability. The closer D is to 0, the better.
Main Sequence and risk zones
Ideal diagonal: balance between abstractness and stability. Formula: D = |A + I - 1|
Concrete and stable components (A≈0, I≈0). Hard to change because of many dependencies.
Abstract and unstable components (A≈1, I≈1). Abstractions without implementations.
Connascence Types
Dependency on entity name
Dependency on data type
Dependency on value semantics
Dependency on algorithm
Dependency on element order
Dependency on execution order
Dependency on timing
Dependency on specific values
Dependency on object identity
Part II: Architectural Styles
Monolithic architectures
Layered Architecture
- •Presentation → Business → Persistence → Database
- •Ease of understanding and development
- ⚠Sinkhole anti-pattern
Pipeline Architecture
- •Pipes and Filters pattern
- •ETL, data processing pipelines
- •Unix philosophy
Microkernel Architecture
- •Core system + plug-in components
- •IDE, browsers, Eclipse
- •Extensibility without changing the kernel
Distributed Architectures
Service-Based Architecture
The “golden mean” between monolith and microservices:
Event-Driven Architecture
Asynchronous communication through events:
Space-Based Architecture
For extreme scalability:
Microservices Architecture
Maximum service independence:
Comparison of architectural styles
| Style | Deployability | Scalability | Simplicity | Cost |
|---|---|---|---|---|
| Layered | ⭐ | ⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| Service-Based | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ |
| Event-Driven | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐ | ⭐⭐ |
| Microservices | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐ | ⭐ |
Part III: Soft Skills of an Architect
Architecture Decision Records (ADR)
Documentation of architectural decisions:
Architecture Fitness Functions
Automatic architecture compliance check:
Key insight: An architect is not only a technical specialist, but also a leader, negotiator and communicator. 50% of an architect’s success is the ability to explain and “sell” their solution to stakeholders.
Application to System Design Interview
What to use in an interview
- •Architecture Characteristics: explicitly name the selected characteristics and trade-offs
- •Architectural styles: justify your choice of style (Event-Driven vs Service-Based)
- •Trade-off analysis: show an understanding of the trade-offs
- •ADR approach: structure the explanation as Context → Decision → Consequences
Common mistakes
- •Choosing microservices “by default” without justification
- •Ignoring operational characteristics (functional requirements only)
- •Absence of explicit trade-offs in the solution
- •Over-engineering for simple tasks
Continuation
Building Evolutionary Architectures
Next book in the series: Fitness Functions, Connascence and the Evolution of Architecture
Verdict
Fundamentals of Software Architecture is a must-read for anyone who wants to understand the architect's role in a holistic way. The classification of architectural styles with a clear analysis of trade-offs is especially valuable. For the System Design Interview, the book provides an excellent framework for structuring answers and justifying decisions. Recommended after studying basic books on System Design.
Related chapters
- What software architecture is and why it matters in System Design - provides the overarching architecture frame and helps connect the book’s ideas with real design work.
- Clean Architecture (short summary) - deepens boundaries and dependency management to reduce coupling across modules and teams.
- A Philosophy of Software Design (short summary) - complements this book with practical complexity management and interface design principles.
- Software Architecture: The Hard Parts (short summary) - extends trade-off analysis into distributed concerns: saga patterns, orchestration, and data decomposition.
- Building Evolutionary Architectures (short summary) - shows how to operationalize architecture decisions with fitness functions and controlled evolution.
- Architecture at scale: how we make architecture decisions - translates the book into org-level practice with RFC/ADR workflows, decision logs, and lightweight governance.