The hard parts of architecture do not begin when you pick a fashionable pattern. They begin when the wrong service or data boundary quietly makes the system expensive to change for years. This chapter is about exactly those decisions.
On the ground, it pulls monolith decomposition, data ownership, distributed transactions, sagas, orchestration vs choreography, and contract evolution into one frame. That makes it easier to reason about migration cost, consistency risk, and team impact rather than just the target diagram.
In difficult interview scenarios and architecture reviews, the chapter gives you mature language for the uncomfortable questions: how to split services, where data ownership should live, when async coordination is justified, and how to proceed when no perfect answer exists.
Practical value of this chapter
Hard trade-offs
Builds practical judgment for distributed data, transactional boundaries, and consistency issues.
Pattern selection
Teaches context-based selection across orchestration/choreography and sync/async approaches.
Risk management
Adds early failure-mode analysis before decisions reach production environments.
Interview hard mode
Prepares for advanced interview prompts where mature trade-off reasoning matters most.
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.
Book 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”.
Related chapters
- What is software architecture and why is it in System Design? - provides the architecture frame to reason about hard trade-offs and long-term system evolution.
- Fundamentals of Software Architecture (short summary) - builds the baseline on architecture characteristics and styles before tackling complex distributed scenarios.
- Building Microservices (short summary) - extends service decomposition into practical boundaries, integration choices, and operational microservice concerns.
- Learning Domain-Driven Design (short summary) - connects decomposition to domain boundaries and team responsibility modeling.
- Decomposition strategies - adds practical techniques to split systems into modules and services under dependency and change pressure.
- Building Evolutionary Architectures (short summary) - complements this chapter with fitness functions and testable constraints for controlled architecture evolution.