Modular Monolith vs Microservices: When To Choose Each (2026)

Q: What is a modular monolith?

A modular monolith is a single deployable application composed internally of strictly bounded modules with explicit public interfaces. It is one process, one binary, one deployment — but inside, it is partitioned into modules that each represent a bounded context, expose a narrow public service or event interface, and are forbidden from reaching into each other's internals. The User module exposes UserService and emits UserCreated events; the Order module consumes those through an in-process event bus and uses UserService for lookups, but never queries the User module's tables directly, never imports its repositories, and never instantiates its private classes. The boundaries are enforced by code organisation, lint rules, and team discipline. The architecture combines the operational simplicity of a monolith (one deployment, one log stream, one set of dashboards) with the logical separation that would survive a future split into services if and when a real trigger justifies it.

Q: How is a modular monolith different from a regular monolith?

A regular monolith — what people often call a "big ball of mud" — has no internal boundaries. Any class can import any other class, any module can query any database table, and over time the codebase becomes a tangled web in which a change anywhere can break anything. A modular monolith deliberately partitions the codebase into modules with strict, enforced boundaries: each module owns its own data, exposes a public interface, and is forbidden from accessing other modules' internals. The discipline is enforced through directory structure, framework features (such as NestJS's explicit imports/exports), and lint rules that reject illegal cross-module imports. The result is a codebase in which each module could in principle be extracted into a service when justified, but in the meantime they live together and pay none of the operational costs of being separate. Modular is the operative word; without it, the architecture is just a monolith waiting to become unmaintainable.

Q: When should I choose microservices over a modular monolith?

Choose microservices when you have one of the genuine triggers: an engineering organisation of 50+ people split into multiple teams that step on each other inside a monolith; modules with genuinely different hardware requirements (a GPU-bound video processing module and a CPU-bound web module); modules with deploy cadences that cannot be unified (a daily-deploy experimentation engine and a quarterly-deploy regulated billing engine); or contractual multi-tenant isolation requirements that physically separate tenant processing. Do not choose microservices because they are "best practice" — that was the mistake the industry made for a decade. Do not choose them because integration tests are slow (fix the test design). Do not choose them because you want to scale (horizontal monolith scaling handles almost all workloads). The default for new projects in 2026 should be a modular monolith; split only when a real trigger appears, and split surgically, one module at a time, using the Strangler Fig pattern.

Q: How do I enforce module boundaries in a NestJS monolith?

NestJS provides three layers of enforcement. First, the module system itself: each NestModule declares its imports and exports explicitly, so a module can only consume providers that another module has chosen to export — no accidental access to private services. Second, directory structure and TypeScript path mappings: each module lives in its own folder under src/modules/, with internal subfolders (repository, entities, dto) and a single public entry point (the module file plus exported services and events). Third, lint enforcement: tools like eslint-plugin-boundaries, dependency-cruiser, or custom path restrictions reject any import from src/modules/user/repository by anything outside src/modules/user/. Use the in-process event bus (NestJS EventEmitter or @nestjs/cqrs) for asynchronous coupling between modules, exactly mirroring the message-broker pattern that microservices use. Without lint enforcement, the discipline degrades over time as developers under deadline reach across module boundaries for convenience; with it, the boundaries are real and the monolith stays modular.

Q: What is the Strangler Fig migration path?

The Strangler Fig pattern, named after the tree that grows around a host tree until the host is gone, is the standard way to migrate from a monolith to microservices (or back) one module at a time. To extract a module: place an API gateway in front of the monolith routing all traffic through it; choose a low-coupling, high-independence module to extract first (often a read-only reporting module or a self-contained notification module); build the new service; gradually shift traffic to it via the gateway, route by route; verify behaviour and metrics; delete the corresponding code in the monolith only after the new service has been stable for weeks. The same pattern works in reverse to merge services back into a monolith: identify two or three closely coupled services that always deploy together; merge their codebases as separate modules with strict boundaries; deploy the merged binary alongside the existing services; ramp traffic from 1% to 100%; decommission the originals. The migration takes months per module; the hardest part is always the data, not the code.

Q: Why are companies like Shopify and Basecamp staying on monoliths at scale?

Shopify runs its core application as a Rails monolith of millions of lines of code, deliberately partitioned into 100+ components with strict boundary enforcement (using their open-source Packwerk tool). Basecamp and HEY, both run by 37signals (David Heinemeier Hansson, creator of Rails), are public proponents of the monolith default. Their reasoning is consistent: the operational and cognitive costs of microservices grow super-linearly with the number of services, while the benefits (independent team velocity) only materialise above a certain organisational scale and only if the organisation actually has the team-per-service ratio that microservices assume. At Shopify's scale they found that a well-modularised monolith was both cheaper to operate and easier to evolve than the equivalent microservices fleet. Amazon Prime Video published a similar case study in 2023 reverting a microservices-and-Lambda architecture to a monolith with ~90% cost savings. None of these cases argue that microservices are always wrong; they argue that the default was wrong, and that the cost-benefit analysis was not being done honestly.

Q: What are the trade-offs of a modular monolith I should know about?

Three real trade-offs. First, discipline: the boundaries in a monolith are conventions enforced by code review and lint rules, while microservices boundaries are physically enforced by network calls. A team without the discipline to maintain module boundaries will dissolve them under deadline pressure and produce the big ball of mud the modular structure was supposed to prevent. Second, language uniformity: the whole binary is one language and one runtime — the argument "we want Rust for this module" requires extraction to a service. Third, blast radius: a memory leak or crash in one module can take down the whole binary, while microservices' physical separation provides isolation. Mitigations include careful resource management, worker threads or process pools where the language supports them, and the same robustness practices any production service requires. There is also uniform scaling — when one module needs more capacity, the whole monolith scales — but this over-provisioning is usually a rounding error compared to the operational cost of running separate services. The trade-offs are real but, for most teams below microservices-scale, well worth accepting.

Q: Will I regret choosing a modular monolith if my company grows?

Not if the modules are genuinely modular. The whole point of the modular monolith pattern is that each module is designed as if it were a future service: it owns its own schema, exposes a narrow public interface, communicates with other modules through events or service calls (which look identical whether in-process or over the network), and would be ready to extract via the Strangler Fig pattern when a real trigger appears. The cost of starting modular and splitting later is bounded: the boundaries already exist, and the migration is module-by-module surgery. The cost of starting microservices and discovering you didn't need them — having to merge them back together — is much higher because inter-service contracts have already been published, deployment pipelines built, on-call rotations established, and operational habits formed. Starting modular keeps both options open at low cost; starting microservices commits you to that architecture even when a modular monolith would have served better.

Q: How do I handle scaling in a modular monolith?

Horizontal scaling: run multiple instances of the monolith behind a load balancer. This is the same scaling pattern that web applications have used since the 1990s and works well for the vast majority of workloads. Each instance is stateless or pushes its state to a shared database, cache, or message broker; adding capacity is adding instances. The monolith does not need to be small to scale this way — Shopify runs hundreds of instances of its monolith handling Black Friday traffic for a top-10 e-commerce platform. The "scaling" argument for microservices is mostly a misunderstanding: microservices don't scale better than monoliths for typical workloads; they enable independent scaling per service, which only matters when modules have genuinely different scaling characteristics (rare). For asynchronous work, the modular monolith uses an in-process queue or a shared message broker (RabbitMQ, SQS) exactly as a microservices system would. The compute architecture of "monolith behind a load balancer plus background workers plus a message broker" handles enormous scale; the limit is rarely the architecture and almost always the database tier.

Q: What lint rules and tools should I use to enforce monolith modularity?

For TypeScript and NestJS: eslint-plugin-boundaries lets you declare that files in src/modules/user/ can only import from approved paths; dependency-cruiser produces dependency graphs and rejects forbidden cross-module imports in CI; TypeScript path mappings via tsconfig.json paths can hide module internals behind a single barrel export. For Ruby and Rails: Shopify's Packwerk is the de facto standard, declaring "packs" with explicit public APIs and failing CI on illegal cross-pack constants. For Python: import-linter enforces layered architecture rules. For all stacks: a CI step that runs the boundary checker on every pull request, fails the build on violations, and produces a human-readable report of what would be needed to fix the violation. Without automated enforcement, the discipline degrades within months — developers under deadline pressure will reach across boundaries for convenience, and code review alone is too inconsistent to catch every case. With automated enforcement, the modular monolith stays modular indefinitely. Treat boundary enforcement as non-negotiable infrastructure, the same way you treat compilation or unit tests.