Modular Monolith
A single deployable unit internally partitioned into modules with enforced boundaries, explicit interfaces and no shared internal state.
The modular monolith takes the discipline of microservices — clear domain boundaries, owned data, communication only through published interfaces — and declines the distribution. One process, one deployment, one database connection pool, in-process calls that cannot time out.
It is the correct default for most systems and the correct starting point for nearly all of them, because the boundaries are the hard part and they are far cheaper to move while everything is still in one codebase. Get the modules right first; extracting a well-bounded module into a service later is a mechanical exercise, whereas extracting a badly-bounded one is a rewrite.
The failure mode is that the boundaries are not enforced. Without a build-time check — module visibility rules, an architecture test, separate schemas — they erode within a year.