Source
Book Review
Detailed analysis of the book on the tellmeabout.tech blog
Software Architecture: The Hard Parts
Authors: Neal Ford, Mark Richards, Pramod Sadalage, Zhamak Dehghani
Publisher: O'Reilly Media, 2021
Length: 462 pages
Monolith decomposition, saga patterns, orchestration vs choreography and data management in distributed systems.
Original
TranslatedBook structure
The book is divided into two parts, each focusing on key “difficult” decisions:
Part I: Decomposition
How to break a monolith into services: decomposition patterns, defining boundaries, analyzing components and dependencies.
Part II: Data and Transactions
Database partitioning, distributed transactions, saga patterns, eventual consistency and contract management.
Analysis
Part I: Decomposition
Detailed analysis of the first part of the book
Part I: Pulling Things Apart (Decomposition)
Architectural Quantum
Architectural Quantum - minimal independently deployable unit with high functional cohesion:
Key insight: Quantum size determines architectural characteristics. Monolith = one quantum (everything is deployed together). Microservices = many quanta (independent deployment of each).
Decomposition patterns
Tactical patterns
Decomposition Drivers
Analysis
Part II: Putting Together
Analysis of the second part of the book: data and transactions
Part II: Pulling Data Apart
Data Decomposition Drivers
Reasons to share data
- ✓Independent scaling of services
- ✓Fault tolerance
- ✓Different data requirements (GDPR)
- ✓Independent choice of technologies
Reasons NOT to share
- ✗Complex transactions between services
- ✗High consistency requirements
- ✗Frequent cross-service requests
- ✗Complexity of data replication
Analysis
Distributed Transactions
Analysis of distributed transactions and sagas
Distributed Transactions: Sagas
Orchestration Saga
The central coordinator manages all steps:
Choreography Saga
Services react to each other's events:
When to choose what: Orchestration - for complex business processes with clear workflow. Choreography - for simple event chains with minimal dependencies between services.
Analysis
Saga State Management
Analysis of saga state management patterns
Saga State Management
Epic Saga (synchronous)
All services are called synchronously. Simplicity, but high coupling and latency.
Phone Tag (async point-to-point)
Asynchronous calls between services. Less coupling, harder to track.
Fairy Tale (async events)
Complete event-driven architecture. Maximum decoupling, complex debugging.
Analysis
Contracts & Coupling
Analysis of contracts and service connectivity
Contracts & Service Coupling
Types of contracts
Coupling Characteristics
Application to System Design Interview
What to use in an interview
- •Architectural quantum: explain the boundaries of deployment and coupling
- •Saga patterns: demonstrate understanding of distributed transactions
- •Orchestration vs Choreography: justify your choice
- •Data ownership: clearly define which service owns the data
Common mistakes
- •Ignoring distributed transactions when separating services
- •Lack of compensating actions in saga
- •Shared database between “independent” services
- •Synchronous calls everywhere (distributed monolith)
Book
Fundamentals of Software Architecture
Recommended reading before this book
Verdict
Software Architecture: The Hard Parts — a must-read book for those who work with microservices or are preparing for a senior/staff-level interview. The concepts of architectural quantum, saga patterns and data decomposition drivers are directly applicable to the System Design Interview. Read after “Fundamentals of Software Architecture”.