Modular Monoliths and Other Facepalms - Kevlin Henney - NDC London 2026 (Category Architecture)
Interesting. video Kevlin Henney, where he is an evangelist of monoliths, modular monoliths:) To cut it short, he says the problem was not monoliths, but tangled dependencies and blurred boundaries. Microservices do not treat poor decomposition. But they just make mistakes more expensive. (network, consistency, observation, operation). It’s funny that I started sawing my first monolith in T-Bank just in order to push this value to the limit and cross the Rubicon. (The first backend system that I got was made by frontenders for frontenders and resembled noodles - it was impossible to set boundaries differently.). But if you go back to Kevlin’s story, his advice is to start with a well-structured modular monolith. (if there are sustainable drivers) Allocate services.
Separately, I liked the story around the evolution of approaches, as I myself like to build storytelling for my reports. - 1972 David Parnass: Decomposition criteria + information hiding (hide what often changes.) - 1974 Liskov and Zills: abstract data types (ADT)Working with data abstractions - 1997 Foote & Yoder: The anti-pattern Big Ball of Mud (The system crawls into a lump without discipline.) - 2014 Fowler/Lewis: Microservices as a set of independently deployable services (Not "small modules over the network.") - 2014+ Simon Brown: Distributed Big Ball of Mud
When it comes to insights, they are like this. Modularity is a property of code and dependencies, not infrastructure If you don’t keep boundaries within a single process, microservices won’t save you — they’ll just add partial failures and diagnostic complexity.
Architecture is more manifested in dependencies than in diagrams So architecture is possible. (need) Do verifiable: rules → CI → “break the build” on violations.
🧩 Monolith becomes a problem when it becomes tangled monolith. That is, not "one deploy" is bad, but intertwinedness. (cycles, border circumvention, occasional imports, stratification).
🤑 Microservices are an investment (technical + organizational). They are justified when it is really necessary to independently deplore, isolate changes, scale in parts, separate the responsibility of teams. If there are no drivers, you buy overhead without winning.
For developers, such practical conclusions follow. Objective: To make borders real, not decorative Module = unit of evolution, not folder. There is a public API, there is a hidden inside, there are prohibitions on “bypassing”. Dependency direction is more important than layer names Follow the cycles, “back” links, the flow of infrastructure to the domain.
For technical managers, such practical conclusions follow. Architectural labels are no substitute for border management. If the motivation to “give microservices so the code splits itself” is a red flag. First: borders, ownership, rules, review policies, architectural tests. Microservices, by definition, increase:
- Number of deploy units Number of communications Requirements for CI/CD, observability, security, data contracts
A strategy that usually works better:
- Modular monolith - default Microservices – Conscious Investment with Sustainable Drivers
P.S. As usual, the extended version is available. system-design.space.
#Architecture #Software #DistributedSystems #Engineering #Management