Modular monolith
A modular monolith is a single deployable application internally organised into well-defined modules with explicit boundaries, typed contracts between modules, and independent ownership. The pattern captures the benefits of microservices (clear boundaries, team independence) without the operational cost of distributed deployment.
Modular monolith has become the recommended starting architecture for new systems through 2024-2026, replacing the 'microservices by default' fashion of the late 2010s. The argument: most teams adopting microservices weren't ready for the operational complexity (distributed tracing, service mesh, deployment orchestration, eventual consistency) and would have been better served by a well-modularised monolith. The fitness-function discipline matters here: enforce module boundaries in CI (no cross-module imports outside the published interface) and the monolith preserves microservice-like modularity. When and if scale or team-independence requires it, modules become microservices through the strangler-fig pattern.
Discussed in our use-cases
ICP-targeted pages where modular monolith is part of the framing.
Related terms
- Microservices
Microservices is an architectural style where a single application is composed of many small, independently-deployable services, each owning its own data and communicating over the network.
- Evolutionary architecture
Evolutionary architecture is the design approach that explicitly plans for architectural change over time — building in fitness functions, modular boundaries, and incremental migration paths so the architecture can evolve without big-bang rewrites.
- Architecture fitness function
An architecture fitness function is an executable test that asserts an architectural characteristic — coupling between modules, cyclic-dependency absence, response-time budget, dependency direction.