Architectural failure modes are easier to fix when teams can name them early. Chapter 12 turns common microservices smells into explicit anti-patterns: the distributed monolith, service-per-entity decomposition, shared coupling through databases or libraries, nano-services, and slow boundary drift.
Read the lessons in order. The first explains why technically separate services can still behave like one tangled system. The next two cover entity-driven decomposition and hidden shared coupling. The fourth focuses on fragmentation that exceeds the team’s operating capacity. The last lesson shows how once-clean boundaries erode over time through exceptions and shortcuts.
If a system is paying the cost of microservices but not getting clear autonomy, Chapter 12 is where to diagnose why.
In this section
- The Distributed Monolith
A practical lesson on the distributed monolith anti-pattern, how to recognize it in workflow and release behavior, and why platform maturity does not fix weak boundaries by itself.
- Service Per Table or Service Per Entity
A practical lesson on why entity-driven decomposition usually creates thin, chatty services and why tables and nouns are weak substitutes for capability boundaries.
- Shared Database and Shared Library Coupling
A practical lesson on how shared schemas and oversized shared libraries recreate hidden monolith behavior across supposedly separate services.
- Nano-Services and Premature Fragmentation
A practical lesson on nano-services, why tiny deployables can exceed their business value, and how premature fragmentation shifts complexity from code into operations and coordination.
- Boundary Drift Over Time
A practical lesson on how healthy boundaries erode through exceptions, shortcuts, and ownership leakage, and how to detect and correct drift before it becomes the new normal.