A modular monolith is a single application, deployed and released as one unit, that is internally organized into clearly separated modules with defined boundaries and explicit interfaces between them. It looks like a traditional monolith from the outside: one codebase, one deployment pipeline, one running process or a cluster of identical processes behind it. On the inside, it behaves much more like a set of well-organized, individually reasoned-about services that simply happen to share a process and a deployment pipeline instead of running as separate, independently deployed systems.
The reason the modular monolith pattern exists at all is that teams kept getting burned repeatedly in both directions. A traditional, unstructured monolith tends to accumulate tangled dependencies over time, where changing one part of the code has unpredictable effects somewhere else, and eventually nobody fully trusts a change until it's been tested everywhere. Microservices were supposed to fix that by forcing hard boundaries, but they introduced a different tax: network calls where function calls used to be, distributed debugging, and operational complexity that many teams took on before they actually needed it. The modular monolith is a direct response to both failure modes.
What distinguishes a modular monolith from an ordinary monolith is enforced internal structure: modules communicate through defined interfaces, not by reaching directly into each other's internals, and dependencies between modules are explicit and, ideally, checked automatically rather than policed by convention alone. What distinguishes it from microservices is deployment and runtime: everything still ships together, runs in the same process space or the same small set of processes, and shares a database, or at least shares infrastructure, rather than each module owning fully independent infrastructure and a separate deployment cycle.
By 2026, the modular monolith has become the default recommendation for a large share of new backend systems, replacing "start with microservices" as the conventional wisdom of the previous decade. That shift reflects hard-earned experience: plenty of teams adopted microservices before they had the organizational scale or operational maturity to justify the overhead, and paid for it in slower delivery and harder debugging. The modular monolith gives teams a way to keep the option of splitting into services open later, without paying the distributed-systems tax on day one.
This page covers what actually makes a monolith "modular" versus just a big pile of code, how it compares to both a plain monolith and to microservices, where each approach earns its complexity, and how a team builds and maintains real module boundaries once it chooses this path. The durable idea underneath all of it is that architecture should match organizational and operational reality, not an aspiration. Understanding that is what lets a team pick a structure it can actually maintain, instead of one that looks impressive in a diagram but breaks down under its own weight.
It's worth being honest that the term itself has become a little fashionable, which means it sometimes gets applied loosely to systems that are really just monoliths with better intentions. The value of the pattern comes entirely from the enforcement mechanisms behind it, not from the label. A team that renames its folders and calls the result a modular monolith without changing how dependencies are actually managed hasn't gained anything beyond a tidier directory listing.
The word "modular" is doing real work in this term, and it's the part most often skipped in practice. A large codebase organized into folders by feature isn't automatically modular; folder structure is cosmetic unless it's backed by actual, enforced rules about what can call what and what has to go through a defined boundary instead. A genuinely modular monolith defines, explicitly, which modules can depend on which others, and it enforces that boundary through tooling, not just through a diagram in a wiki that nobody consults during a code review.
The core mechanism, the piece that does most of the actual work here, is the interface. Instead of one module reaching directly into another module's database tables or internal functions, it goes through a defined entry point, similar in spirit to how a well-designed API works between separate services, except the call happens in-process rather than over a network. This gives you most of the architectural benefit of service separation, meaning clear ownership and limited blast radius when something changes, without the cost of an actual network hop and everything that comes with it, like retries, timeouts, partial failure handling, and the extra latency a network round trip always adds compared to a direct function call.
Enforcement, more than intention or good documentation, is what actually separates a real modular monolith from a monolith with aspirational module folders. Some teams use compiler or language-level constructs, like separate packages with restricted visibility, to physically prevent one module from importing or reaching into another module's internals directly. Others rely on architectural fitness tests that run in continuous integration and fail the build if a forbidden dependency shows up. Teams that skip enforcement and rely purely on developer discipline tend to watch their boundaries erode within a few quarters, usually starting with one small, well-intentioned shortcut under a deadline.
Data ownership is the other half of the picture, and it's frequently the harder half to get right. A module that owns a set of database tables outright, with other modules accessing that data only through its interface rather than querying the tables directly, keeps the boundary meaningful even under schema changes. A modular monolith that enforces code-level boundaries but lets every module query a shared set of tables directly still has one of the worst problems of an unstructured monolith hiding underneath a nicer directory structure.
This is also why teams that take the pattern seriously often invest in automated checks that run alongside the normal test suite, verifying that no module has quietly started importing another module's internal code or reaching into tables it doesn't own. Catching a boundary violation in a pull request, before it merges, costs a few minutes of a reviewer's attention. Catching the same violation two years later, after a dozen other modules have come to depend on the shortcut, can cost weeks of careful untangling.
Microservices split an application into independently deployable services, each with its own runtime, often its own database, and communication happening over a network, typically through HTTP or a message queue. This buys strong isolation: one service can be scaled, deployed, and even rewritten independently of the others, and a bug in one service is less likely to bring down the whole system. It also buys a substantial amount of operational complexity: service discovery, distributed tracing, network failure handling, versioned APIs between services, and a deployment pipeline for every single service instead of one.
A modular monolith buys most of the organizational clarity, meaning clear ownership boundaries and limited blast radius for changes, without most of that operational cost. Calls between modules are function calls, not network calls, so there's no need to handle partial failure between them the way you would between two independently deployed services. Deployment stays simple: one artifact, one pipeline, one thing to roll back if something goes wrong, rather than needing to reason about which combination of service versions was actually running at the moment of an incident.
What it doesn't buy is independent scaling and independent deployment. If one module needs ten times the compute of the rest of the system, the whole monolith scales with it unless the team has planned around that specific need, since you can't scale a subset of one deployed process independently of the rest. If a team wants to deploy one module's fix instantly without touching or retesting the rest of the system, a monolith, modular or not, makes that materially harder than a true microservice would, since everything ships together as one unit whether the change is small or large.
The trade-off, stated plainly, is operational simplicity versus deployment and scaling independence. Most teams, most of the time, need the former far more than the latter, particularly before they've reached a scale where different parts of the system have genuinely different load profiles or genuinely different teams that need to ship on independent schedules without coordinating a release together.
There's a testing dimension to this trade-off too, one that gets less attention than deployment and scaling but matters just as much day to day. A modular monolith can usually be tested end to end with a single test suite running against a single running instance, which makes integration tests fast and reliable to write. Testing the same end-to-end behavior across a set of independently deployed microservices typically means standing up multiple services together, or relying on contract tests and mocks that verify each service's behavior in isolation but can still miss the ways they actually interact once deployed together in production.
A lot of the swing back toward monoliths, modular ones specifically, comes from teams counting the actual cost of microservices honestly rather than the promised benefit. Independent services sound appealing on a whiteboard. In practice, they require a team to build and maintain infrastructure for service discovery, distributed logging, network retries, and versioned contracts between services, all of which is real, ongoing engineering work that has nothing to do with the actual product being built.
That overhead is a fixed cost that doesn't scale down for a small team. A ten-person engineering team running fifteen microservices spends a disproportionate share of its capacity on the plumbing between services rather than on the product itself, and debugging a single user-facing issue that crosses six services is meaningfully harder than debugging the same issue in one well-organized codebase, since a stack trace that stays within one process is a lot easier to reason about than one that spans a network boundary and several separately deployed systems.
The modular monolith lets a team get the main benefit teams actually wanted from microservices, which was usually clear boundaries and reduced coupling between parts of the system, without forcing them to also take on distributed systems problems they weren't ready to operate. This matters most for teams below a certain organizational size, where the number of engineers per module would be too small to justify a fully separate service, on-call rotation, and deployment pipeline for each one.
It's also a more honest starting point for a system whose real boundaries aren't fully known yet, which describes most new products in their first year or two. Splitting into services requires guessing where the boundaries actually belong, and guessing wrong is expensive to undo once services are independently deployed and other systems depend on their specific network contracts. A modular monolith keeps those boundaries logical rather than physical, so a wrong guess about where a boundary belongs costs a refactor inside one codebase, not a migration across independently running systems.
Hiring and onboarding play into this shift as well, in ways that don't show up on an architecture diagram but do show up in delivery speed. A new engineer joining a team running a modular monolith can usually get a single codebase running locally in an afternoon and start contributing within their first week. Joining a team running two dozen microservices often means understanding which subset of those services actually needs to run locally to test a given change, along with the tooling built specifically to make that possible, which is its own onboarding curve layered on top of learning the product itself.
A modular monolith fits well for most product teams building a new system, teams below a certain size where each module doesn't have a dedicated group of engineers, and any situation where the different parts of the system have roughly similar load and scaling needs. It also fits well when the team is still learning where the real seams in the domain are, since keeping boundaries in code rather than in infrastructure makes those boundaries cheap to adjust as understanding improves.
Microservices earn their complexity when a team has reached a scale where different parts of the system genuinely need independent deployment schedules, usually because different teams own different parts and coordinating a shared release across all of them has become a real bottleneck slowing delivery down. They also earn it when specific components have wildly different scaling profiles, like a video processing pipeline that needs to scale independently and very differently from a billing system in the same product, making it wasteful or even technically impractical to scale them together as one unit.
They also make sense when different parts of a system have genuinely different technology needs, like a machine learning inference service that benefits from a different language or runtime than the rest of the application, where forcing everything into one process would mean compromising on the tools best suited to a specific job. In these cases, the cost of running separate services is justified by a real, specific constraint, not by a general belief that microservices are simply the more modern or more scalable way to build.
The mistake to avoid in both directions is choosing an architecture based on what a well-known company does at a scale your team hasn't reached, rather than the constraints your own team actually has today. Plenty of organizations copied a microservices architecture built for a much larger engineering team and inherited the operational cost without ever hitting the scale that would have justified it. The reverse mistake, staying in a poorly modularized monolith long past the point where a real, evidenced need for service separation has emerged, causes its own kind of pain, usually showing up as slow deploys and a codebase nobody fully trusts to change safely.
A useful gut check is to ask what specific, current problem microservices would solve that a well-enforced modular monolith wouldn't, and to demand a concrete answer rather than a general sense that services are the more scalable path forward. If the honest answer is "nothing specific yet, but we might need it eventually," that's usually a sign the team isn't at the point where the added complexity pays for itself.
Start by defining modules around business capabilities, not technical layers. A module organized around "billing" or "user accounts" tends to hold up better over time than one organized around "the database layer" or "the API layer," because business capabilities change together and technical layers get pulled in every direction by every feature that touches them. Getting this grouping right at the start saves a lot of painful re-organization later, once real usage patterns reveal where the natural seams actually sit.
Next, decide on enforcement before writing much code, not after boundaries have already started blurring under deadline pressure. Whether that's language-level module boundaries, a linting rule that fails a build on a forbidden import, or an architectural test that runs in continuous integration, pick a mechanism and turn it on early. Boundaries that rely purely on documentation and team discipline degrade reliably under delivery pressure, usually starting with a single well-intentioned shortcut that everyone agrees is a one-time exception and then quietly isn't.
It's worth picking an enforcement mechanism that fails loudly and immediately, ideally in the same pull request where the violation was introduced, rather than one that surfaces problems in a slower audit or a quarterly review. The faster the feedback loop between a boundary violation and someone noticing it, the less likely that violation is to become the pattern the next three changes quietly copy.
Give each module ownership of its own data, even if all modules technically share one physical database. Other modules should go through the owning module's interface to read or write that data rather than querying its tables directly, since shared, unrestricted table access is one of the most common ways a modular monolith's boundaries quietly collapse into the same tangle a plain, unstructured monolith would have had from the start.
Finally, revisit the module boundaries periodically as the product and team evolve, rather than treating the initial split as permanent and untouchable. Some modules will turn out to be too large and need splitting further. Others will prove small enough to merge back together, since a module boundary with no evidenced value is just added ceremony for anyone trying to make a small change. The goal is boundaries that reflect the real shape of the domain and the team, not a diagram that stopped being accurate the month it was drawn.
It also pays to assign clear ownership of each module to a specific person or small group, even if the whole team can technically touch any part of the codebase. Ownership gives someone a reason to notice when a boundary starts drifting and the standing to push back on a shortcut before it becomes a habit other engineers copy. A modular monolith with no ownership model tends to degrade the same way an unowned shared codebase always does, just with extra folders.
A modular monolith is a single deployed application that is internally organized into modules with clearly defined boundaries and interfaces, giving a team much of the organizational clarity of separate services without the operational overhead of running them independently.
A regular monolith has no enforced internal structure, so dependencies between parts of the code tend to tangle over time, while a modular monolith explicitly defines and enforces which modules can depend on which others, usually through tooling rather than convention alone.
Microservices are independently deployed, often with their own databases and communicating over a network, while a modular monolith ships as one deployable unit with modules communicating through in-process function calls rather than network requests.
Often yes, but each module should own its own set of tables and be the only module allowed to query them directly, with other modules accessing that data through the owning module's interface rather than reaching into its tables themselves.
Yes, and this is one of its main advantages. Because the module boundaries are already defined and enforced in code, splitting a specific module out into its own service later is a much smaller, more contained change than untangling boundaries that were never made explicit in the first place.
Many teams adopted microservices before they had the organizational scale or operational maturity to justify the overhead, and found that the added complexity of distributed systems slowed delivery down more than the architecture's promised benefits sped it up.
Boundary erosion under delivery pressure is the biggest risk. Without tooling that actually enforces the separation between modules, developers under deadline pressure tend to take shortcuts that quietly turn a modular monolith back into an ordinary tangled one.
It can be, specifically around independent scaling of individual components, since the whole application scales together as one unit. For most teams below a significant scale, this limitation doesn't bite in practice, and it only becomes a real constraint once specific modules have very different load profiles.
The clearest signal is a concrete, evidenced constraint, such as different teams needing independent deployment schedules that a shared release process can no longer accommodate, or a specific module needing scaling or technology choices the rest of the system can't reasonably support.
