Fundamentals of Software Architecture

What the book covers

The book treats architecture as an engineering practice rather than a set of favourite patterns. It works through:

• Architecture characteristics: the "-ilities" (scalability, availability, elasticity, testability and so on), how to find the ones that actually matter for a system, and how to measure them.
• Modularity and components: how to identify components and decide their granularity.
• Architecture styles: layered, pipeline, microkernel, service based, event driven, space based, orchestration driven service oriented, and microservices, each rated against the characteristics it supports well or badly.
• Techniques and soft skills: making and recording decisions, analysing risk, diagramming and presenting architecture, negotiating, leading teams and developing a career path as an architect.

First or second edition?

The link on this page points to the 2020 first edition. The second edition (2025) adds five new chapters, including one on the modular monolith style, a chapter on architectural patterns, a chapter on the intersections of architecture with other concerns, and a revisit of the "laws of software architecture" with a new law and corollary. It also makes the styles chapters more consistent, adding cloud considerations, data topologies, team topologies and governance for each style. If you are buying now, get the second edition.

The idea worth taking

The central lesson is that everything in architecture is a trade off, and "it depends" is only a good answer if you can say what it depends on. The book teaches you to list those factors explicitly (which characteristics matter, what each style gives up) instead of reaching for a preferred style. That habit alone improves design reviews and design interviews.

Is it right for you?

• Yes if you have a few years of experience, are becoming a tech lead or senior engineer, or keep being asked "why this architecture?"
• Maybe later if you are a student or junior developer. The book assumes you have seen real systems and felt the pain of a bad structure. Without that, the styles can feel abstract.
• Not a system design interview book. It will not walk you through designing a URL shortener. It teaches you to be responsible for a system for years, including communicating and living with decisions.

How to read it

• Read Part I (foundations and characteristics) carefully. It gives you the vocabulary the rest depends on.
• Treat the styles chapters as reference. Read the ones relevant to systems you work on now, and compare their ratings with your own experience.
• Do not skip the soft skills part. For many readers it is the most practical section.
• Take one system you know and write down its top three characteristics and which style it follows. Then ask whether the style actually fits.

Pair it with

• Software Architecture: The Hard Parts by the same authors (with Pramod Sadalage and Zhamak Dehghani), for detailed trade off analysis in distributed systems.
• Building Microservices by Sam Newman if you are specifically working with services.
• Martin Fowler's architecture articles for original sources on many of the patterns discussed.

Best for: mid level and senior engineers moving toward architecture or technical leadership who want a structured way to reason about trade offs.