Modular Monoliths: The Middle Ground Between Monoliths and Microservices

For many years, software architecture discussions have been dominated by a seemingly endless debate: Monoliths versus Microservices.

On one side, monoliths are often criticized for becoming large, difficult to maintain, and difficult to scale. On the other side, microservices are often praised for independent deployment and scaling flexibility, but they also introduce significant operational complexity.

What is often overlooked is that these are not the only two options.

A growing number of engineering teams are adopting a third approach known as the Modular Monolith.

Rather than treating architecture as a choice between a single large application and hundreds of distributed services, a modular monolith combines the simplicity of monolithic deployment with the maintainability and separation of concerns commonly associated with microservices.

For many organizations, especially startups, SMEs, and even some large enterprises, a modular monolith offers a practical and sustainable architectural approach.

A modular monolith is a single deployable application that is internally divided into well-defined modules.

Each module:

• Has a clear responsibility.
• Owns its own business logic.
• Exposes interfaces to other modules.
• Hides its internal implementation details.

The application is still deployed as a single executable or service, but internally it is structured as a set of clearly separated subsystems.

For example:

All modules run within the same process, but each maintains clear boundaries.

A traditional monolith often evolves into something like this:

Over time:

• Components start calling each other directly.
• Business logic becomes scattered.
• Dependencies become tangled.
• Changes in one area begin affecting unrelated areas.

This phenomenon is commonly called a Big Ball of Mud.

A modular monolith addresses this by enforcing module boundaries:

Modules communicate through well-defined contracts rather than directly accessing one another’s internal code.

Microservices have become extremely popular because companies such as Netflix, Amazon, Uber, and Spotify have publicly discussed their success with distributed architectures.

However, many organizations copy the architecture without operating at the same scale.

A startup with:

• Five developers
• One product
• A few thousand users

often does not face the same problems as a company operating hundreds of services across multiple data centers.

As a result, teams end up introducing:

• Service discovery
• API gateways
• Distributed tracing
• Container orchestration
• Message brokers
• Network security layers

before they actually need them.

The result is an architecture that is often more complicated than the business itself.

A modular monolith is deployed as a single unit.

Instead of a sprawling distributed deployment footprint, you deploy a much simpler runtime shape:

This dramatically reduces operational overhead.

Developers can:

• Run the entire system locally.
• Debug across modules.
• Step through code without network boundaries.
• Avoid the overhead of distributed debugging.

This often leads to faster development cycles.

It also shortens feedback loops. Instead of waiting for multiple services, containers, queues, and remote dependencies to line up correctly, developers can usually test a change inside one application boundary. That matters because the faster a team can validate an idea, the faster it can improve the product.

Since modules communicate in-process:

communication is typically faster and consumes fewer resources.

That does not mean performance is automatically solved, but it does remove many of the overhead costs that come with remote communication. For latency-sensitive workflows, this can make a meaningful difference in both throughput and operational simplicity.

A properly designed modular monolith encourages:

• Domain-driven design
• Clear ownership
• Separation of concerns
• Reduced coupling

Each module behaves like a mini-application inside the larger application, provided its boundaries are actively enforced.

This is one of the most important architectural benefits. When the order domain is clearly separated from billing, inventory, or notification, teams can reason about change more safely. Features become easier to design, test, and refactor because the boundaries of responsibility are visible rather than implied.

Microservices often require:

• Multiple servers
• Containers
• Load balancers
• Monitoring systems
• Service meshes

A modular monolith can often operate efficiently with significantly less infrastructure.

This is especially attractive for startups and SMEs, although a monolith can become less cost-efficient when one heavily used capability forces the entire application to scale together.

In practice, this means teams can often delay spending on orchestration, observability, networking layers, and deployment automation that only become necessary at larger scale. That delay is valuable because it keeps engineering effort focused on product delivery rather than premature platform complexity.

Modular monoliths are not a silver bullet.

They require discipline.

Without proper enforcement:

• Modules can begin accessing each other’s internals.
• Dependencies can become tangled.
• The application can slowly degrade into a traditional monolith.

The key is maintaining strict boundaries.

For example:

The second approach breaks encapsulation and undermines modularity.

Once teams start bypassing module APIs, the design may still look modular on paper, but it no longer behaves that way in reality. That is usually how a well-structured system begins sliding back toward the same tight coupling and fragility that modularization was meant to prevent.

A modular monolith is often an excellent choice when:

A team of:

• 3 developers
• 10 developers
• 20 developers

can often move much faster with a modular monolith than with dozens of services.

Small teams usually benefit more from clarity and speed of execution than from distributed autonomy. When the same people are already collaborating closely, splitting the system into many deployable units often adds coordination cost without delivering a proportionate advantage.

When requirements change frequently:

• Features are added.
• Workflows change.
• Business rules evolve.

Refactoring a modular monolith is usually easier than coordinating changes across multiple services.

That flexibility matters in the early and middle stages of a product. When the domain is still taking shape, the architecture should make change cheaper, not harder. A modular monolith gives teams room to restructure boundaries as the business becomes clearer.

Many engineering teams underestimate the operational complexity of distributed systems.

A modular monolith allows teams to focus on solving business problems rather than managing infrastructure.

That simplicity is not about avoiding rigor. It is about applying complexity where it creates value. If the business does not yet need service discovery, cross-service observability, or independent deployment pipelines, then introducing them early may create more friction than benefit.

Microservices become attractive when:

• Different modules require independent scaling.
• Teams become very large.
• Independent deployment becomes critical.
• Different services require different technologies.
• Organizational complexity exceeds application complexity.

Examples include:

• Large e-commerce platforms
• Global streaming services
• Massive SaaS platforms
• Multi-tenant enterprise systems

At this scale, the benefits of service separation may outweigh the additional complexity.

This is the key distinction: microservices are justified by real pressure, not by architectural fashion. When technical and organizational demands genuinely require independent deployment and scaling, service boundaries can become a practical advantage rather than an expensive abstraction.

One of the most overlooked advantages of a modular monolith is that it can serve as a stepping stone to microservices.

If modules have been properly designed:

Then each module can later be extracted into its own service if needed, especially when it already has clear contracts, isolated data ownership, and limited coupling to shared transactions.

This allows organizations to:

1. Start simple.
2. Grow naturally.
3. Introduce complexity only when justified.

Instead of starting with microservices and hoping the business eventually grows into them, a modular monolith allows the architecture to evolve alongside the business.

Many experienced architects have begun revisiting monolithic architectures.

Not because microservices are bad, but because many organizations discovered that:

Distributed systems are difficult.

Every network call introduces:

• Latency
• Failure points
• Security concerns
• Monitoring requirements
• Operational complexity

A modular monolith avoids many of these problems while still maintaining strong architectural boundaries.

That is why many teams have become more skeptical of premature distribution. The lesson from industry is not that microservices are wrong; it is that the cost of distribution is real, persistent, and easy to underestimate when teams focus only on the upside.

In many cases, the real question is not:

Should we use microservices?

but rather:

Have we actually outgrown a modular monolith?

Many successful systems start as modular monoliths.

One of the clearest public examples is Shopify. In its engineering articles, Shopify explicitly describes its core platform as a Rails modular monolith and explains how it invested in stronger component boundaries, clearer ownership, and tooling to make a very large codebase feel smaller and safer to change.

That example matters because it shows this architectural style is not limited to small internal tools or early startup products. A modular monolith can support significant scale when teams treat boundaries, contracts, and dependency management as first-class engineering concerns.

To make that concrete, consider the kind of modular structure a digital commerce platform might use internally:

Instead of building separate services from day one, the system could be structured as modules:

Each module has clear responsibilities while remaining inside a single deployable application.

This approach provides:

• Lower latency between modules.
• Easier deployment.
• Simpler debugging.
• Reduced operational complexity.

That is also why Shopify’s example is useful. The lesson is not that every company should copy Shopify’s exact implementation details. The lesson is that a large business can keep a monolithic deployment model while still pushing hard on modularity, ownership, and architectural discipline.

Specific modules should only be extracted into separate services when scaling, team autonomy, or deployment requirements justify doing so.

This is what makes the modular monolith such a useful default for many products. It gives a system enough internal structure to remain maintainable while avoiding the immediate cost of distributing every capability into its own runtime boundary.

The easier it becomes to generate code, the more important it becomes to decide what should exist in the first place. AI can help implement an architecture, but it does not automatically validate that the architecture is justified. Human judgment is still needed to decide whether an additional boundary creates clarity or just more work.

The software industry often treats architecture as a choice between two extremes: a giant monolith or a distributed microservice ecosystem.

In reality, a modular monolith offers a powerful middle ground.

It provides:

• The simplicity of monolithic deployment.
• The maintainability of modular design.
• The performance of in-process communication.
• A natural migration path toward microservices

For many organizations, the goal should not be to build microservices as quickly as possible.

The goal should be to build software that is maintainable, scalable, and aligned with actual business needs.

Sometimes, the most sophisticated architectural decision is choosing not to distribute your system until there is a clear reason to do so.

In other words, architectural maturity is not measured by how many services a company runs. It is measured by how well the chosen design supports the product, the team, and the pace of change the organization actually faces.

Just as microservices are not the goal, modular monoliths are not the goal either.

The goal is to solve business problems effectively.

Architecture should be chosen based on the realities of the product, the team, and the organization, not because a particular approach happens to be fashionable.

The best architecture is often not the most complex one.

It is the one that delivers value while keeping complexity under control.