A modular monolith story matters because it gives teams permission not to rush into microservices just because the idea sounds modern.
In real design work, the chapter shows how module boundaries, dependency discipline, and an intentional path toward services can improve control without immediate operational overhead.
In interviews and engineering discussions, it helps talk about premature decomposition, team overload, and the false sense of maturity often hidden behind the word microservices.
Practical value of this chapter
Design in practice
Separate real domain constraints from fashion-driven “microservices first” decisions.
Decision quality
Use modular monolith intentionally when team scale and load do not justify service split yet.
Interview articulation
Demonstrate maturity: choose architecture shape by context, not trend pressure.
Failure framing
Avoid premature decomposition and operational overload of teams.
About the talk
Modular Monoliths and Other Facepalms
A walkthrough of why a modular monolith is not a new style, but a return to engineering discipline: information hiding, module boundaries, and verifiable dependencies.
Talk
Modular Monoliths and Other Facepalms
Kevlin Henney's NDC London talk about modularity, boundaries, and the cost of distributed architecture.
Main idea
The problem is usually the boundary, not the deployment model
Microservices do not fix poor decomposition automatically; they mainly make mistakes more expensive.
This chapter treats the modular monolith as a disciplined architecture form, not as a compromise between “old” and “new”. Henney's point is that information hiding, module boundaries, and explicit dependency rules need to exist before a team chooses independently deployable services. Without that foundation, distribution can easily become a distributed monolith.
Source
Microservices
Definition of microservices and the basic trade-offs behind independent deployability.
Main points of the talk
A modular monolith is a return to engineering basics
The point of the talk is that modularity, information hiding, and componentization existed long before microservices became fashionable.
Microservices were often used as forced partitioning
Splitting the system across the network can feel tempting when a monolith has lost healthy boundaries, but the network does not create those boundaries for the team.
The false choice is monolith versus microservices
Architecture should be judged by the quality of boundaries, contracts, and dependencies, not by the number of running processes.
Classic decomposition principles still matter
Parnas, ADT, and component thinking remain practical foundations for architecture today.
Distribution amplifies poor architecture
Moving weak structure onto the network often creates a distributed monolith: the same coupling remains, but operations become harder.
Practical takeaway: strengthen the modular monolith first
Start with clear modules, then extract services gradually when independent deployability has durable business drivers.
How the idea of modularity evolved
The history shows that the conversation about modules started long before microservices and kept returning to one question: where is the stable responsibility boundary?
D. Parnas - decomposition criteria and information hiding
The core idea is that a module should hide implementation detail and hold a stable responsibility boundary.
Liskov & Zilles - abstract data types (ADT)
Data abstraction strengthened a contract-oriented way of designing interactions between parts of a program.
Foote & Yoder - the Big Ball of Mud anti-pattern
The paper shows how systems drift into tangled dependency structures when boundaries are not protected.
Lewis & Fowler - microservices as independently deployable services
The value of microservices is tied to independent deployment, not to the label itself.
Simon Brown - the distributed version of Big Ball of Mud
Distribution raises the cost of architectural mistakes when boundaries are not already clear.
Modular monolith as a return to modularity
The framing is a return to basic engineering discipline, not the arrival of a new architecture style.
Takeaways for developers
- Modularity is a property of dependencies and contracts, not infrastructure or service count.
- Turn architecture into checkable dependency rules: cycles, import direction, and layer boundaries.
- A name is not enough: boundaries need to be visible in code, CI, and architecture tests.
- Extract services only around stable business boundaries and a real need for independent deployment.
Takeaways for tech leads
- Make the modular monolith the default strategy and microservices a justified investment.
- Budget for the cost of distribution: observability, security, delivery platform, and data consistency.
- Manage architecture with structure metrics: dependency graphs, forbidden dependencies, cycles, and drift between modules.
- Formalize module ownership and architectural violation policy: current baseline plus a debt-reduction plan.
Practical plan for 2-4 weeks
- 1Name 3-7 module boundaries and generate a dependency graph from the codebase.
- 2Add 5-10 architecture rules to CI: layers, cycles, and forbidden imports.
- 3Set a violation baseline: no new violations, and a clear plan to reduce the old ones.
- 4Review service candidates only where there are separate SLAs, release cycles, and a clear owner for change.
When to stay in a monolith and when to extract services
Modular monolith as the baseline strategy
If independent deployment is not a durable requirement yet, invest in module boundaries, architecture tests, and clear change ownership inside one process.
Microservices as an intentional step
Extract services when there are clear drivers for independent deployability, separate SLAs, partial scaling, and readiness to pay the cost of distribution.
Risks and limitations
- Moving to microservices without mature boundaries often produces a distributed monolith and higher operating load.
- The label “modular monolith” becomes marketing if dependency rules are not testable.
References
- YouTube - Modular Monoliths and Other Facepalms (Kevlin Henney)
- Martin Fowler - Microservices
- Simon Brown - Distributed Big Balls of Mud
- Big Ball of Mud (Foote & Yoder)
- Parnas paper (annotated copy)
- ArchUnit (Java)
- ArchUnitNET (C#)
- dependency-cruiser (JS/TS)
- import-linter (Python)
- Building Microservices, 2nd Edition (Sam Newman)
Related chapters
- Monolith to Microservices (short summary) - A practical migration playbook: Strangler Fig, Branch by Abstraction, and safe service extraction from a legacy monolith.
- Building Microservices (short summary) - The service-architecture target state and operating trade-offs after the modular-monolith phase.
- Decomposition Strategies - A bounded-context decomposition flow with dependency control to avoid ending up with a distributed monolith.
- Why microservices and integration are needed - System-level framing for when microservices are actually justified and what integration surface you need to sustain.
- Learning Domain-Driven Design (short summary) - DDD foundations for domain boundaries and change ownership that make a modular monolith a stable architecture baseline.
- Evolutionary architecture in practice - How to encode architectural boundaries as fitness functions and control structural drift through CI.