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



Interplay of coupling and cohesion

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

Types of coupling


DDD stands for Domain-Driven Design.

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

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.

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