Figure 1: “Building Microservices (2nd edition)” along my notes

Figure 1: “Building Microservices (2nd edition)” along my notes

During my overall IT carreer I came across different architectural design patterns where oppinions differ on the question if they’re the right ones for the problems/challanges teams are dealing with. Before reading this book I was familiar with some of the microservices concepts but it was some article (on modern architectures) that rouse my attention and introduced me to Sam Newman. I was reading the (German) iX Magazin about modern architectures. At the same time I was surprised to read about the similarities between Hexagonal Architecture and microservices. But also topics like DDD, CD, CI are bound together in way that you need to take a hollistic approach to (building) microservices.

I recommend this book Along with Martin Fowlers extensive arcticles on microservices. to anyone willing to spend some time (book has ca. 500 pages) learning about Information hiding, communication between microservices, proper teams setup, role of (IT) architects and much more. Fair enough the author emphasizes multiple time the complexity of decoupling existing services (monoliths) into smaller, independent ones (microservices). The book recommendations in each chapter also give a great hint where you can enlarge upon a specific topic.

What follows next is an ORG mode / outline style collection of notes, thoughts and quotes from the book.

Ch. 1: What are Microservices?


Microservices are independently releasable services that are modeled around a business domain. A service encapsulates functionality and makes it accessible to other services via networks.

Key Concepts


Pain Points

Ch. 2: How to model microservices

Information hiding



Interplay of coupling and cohesion

A structure is stable if cohesion is strong and coupling is low.

Types of coupling

Domain coupling

Pass-through coupling

Common coupling

Content coupling


DDD stands for Domain-Driven Design.


Event Storming

Boundaries between microservices

There are some factors when defining clear boundaries between microservice

Ch. 3: Split the monolith

Decomposition patterns

Data Decomposition concerns

Ch. 4: Communication styles


Ch. 5: Implementing communication

Criterias for ideal technology

Technology choices

API Gateway

Ch. 6: Workflow

Distributed Transactions

Two-phase Commits (2PC)



Ch. 7: Build

Ch. 8: Deployment

Principles of Microservices Deployment

Ch. 10: From monitoring to obersavability

The observability of a system

Alert fatigue

Alert fatigue—also known as alarm fatigue—is when an overwhelming number of alerts desensitizes the people tasked with responding to them, leading to missed or ignored alerts or delayed responses – Source Also a good reading: Alarm design: From nuclear power to WebOps.

What makes a good alert

An alert has to be:

On the importance of testing quote

“Not testing in production is like not practitioning with the full orchestra because your solo sounded fine at home”

Semantic monitoring


Ch. 11: Security

Lifecycle of secrets

Ch. 12: Resiliency


Ch. 14: User interfaces

Stream-aligned teams



Ch. 15: Organizational structures

Conways Law

“Any organization that designs a system will inevitably produce a design whose structure is a copy of the organizations communication structure” - Melvin Conway

All about people

“Whatever industry you operate in, it is all about your people, and catching them doing things right, and providing them with the confidence, the motivation, the freedom and desire to achieve their true potential” - John Timpson Also interesting is the concept of paved roads, where best-practices are available but deviations are also allowed.

Ch. 16: The evolutionary architect

Role of architects

Buildings and software

The comparison with software should be obvious. As our users use our software, we need to react and change. We cannot foresee everything that will happen, and so rather than plan for any eventuality, we should plan to allow for change by avoiding the urge to overspecify every last thing. Our city (the system) needs to be a good, happy place for everyone who uses it. One thing that people often forget is that our system doesn’t just accommodate users; it also accommodates developers and operations people who also have to work there, and who have the job of making sure it can change as required.


Governance ensures that enterprise objectives are achieved by evaluating stakeholder needs, conditions and options; setting direction through prioritisation and decision making; and monitoring performance, compliance and progress against agreed-on direction and objectives. – Cobit 5

Responsibilities of the evolutionary architect

Book recommendations