Microservices vs Modular Monolith: When to Choose Each Approach

Introduction

The debate between microservices and monolithic architectures has evolved. A decade ago, microservices were hailed as the silver bullet for scaling and agility. Today, many teams realize that microservices come with significant complexity, while a modular monolith offers a compelling middle ground. This post explores both approaches with practical guidance on when to use each.

Understanding the Two Architectures

Monolithic Architecture

A monolith is a single deployable unit containing all application logic. While simple to start, traditional monoliths often become tangled, making changes risky.

Modular Monolith

A modular monolith keeps a single deployment unit but enforces strict boundaries between modules. Each module has well-defined interfaces and internal implementation details hidden from others. This approach brings many benefits of microservices—like separation of concerns—without the distributed system overhead.

Microservices

Microservices split functionality into independently deployable services, each with its own database and communication via network calls (e.g., HTTP/REST or messaging). This maximizes autonomy but introduces network latency, data consistency challenges, and deployment complexity.

Key Trade-offs

Aspect	Modular Monolith	Microservices
Deployment	Single artifact, simple	Multiple services, CI/CD per service
Team autonomy	Lower (shared codebase)	High (each team owns services)
Performance	In-process calls, fast	Network calls, higher latency
Scalability	Scale entire app	Scale individual services
Complexity	Lower (no distributed system issues)	Higher (service discovery, tracing, eventual consistency)
Testing	Easier (integration tests)	Harder (contract tests, mocking)

Decision Framework: When to Choose Which

Choose a Modular Monolith if:

1. Your team is small (<10 people). Microservices overhead (deployment pipelines, monitoring) drains productivity.
2. You're building a product with clear bounded contexts but no need for independent scaling. For example, an e-commerce system with modules: catalog, orders, payments.
3. Performance is critical and inter-service communication via network would degrade user experience.
4. Your domain is mostly transactional with strong consistency requirements. Microservices often force eventual consistency, complicating business logic.
5. You're at an early stage and need to iterate quickly. A modular monolith lets you refactor later into microservices if needed.

Choose Microservices if:

1. You have multiple teams >10 people, each owning separate business capabilities. Microservices allow independent development and deployment.
2. Different services have different scalability needs. For example, a video processing service might scale separately from an API gateway.
3. You need polyglot persistence – different data stores for different services (e.g., graph DB for recommendations, document store for content).
4. Your organization is big enough to invest in infrastructure (service meshes, event buses, monitoring).

Practical Example: E-Commerce System

Modular Monolith Implementation

With a modular monolith, each module has its own schema and public API:

// Order module's public interface
public interface OrderService {
    Order createOrder(Cart cart);
    void shipOrder(String orderId);
}

// Payment module's public interface
public interface PaymentService {
    PaymentResult processPayment(Order order, CreditCard card);
}

Modules communicate through interfaces, not direct database access. The monolith is deployed as a single JAR or container.

Microservices Implementation

Each service runs independently:

// Order Service (Node.js + MongoDB)
POST /orders { cartId, customerId }

// Payment Service (Java + PostgreSQL)
POST /payments { orderId, amount, creditCardInfo }

They communicate via REST or messaging (e.g., Kafka).

Migration Path: From Monolith to Microservices

Many successful systems start as a modular monolith. Martin Fowler advocates this approach (see source). Once the module boundaries are stable, extract modules into services if needed.

Sample migration steps:

1. Identify bounded contexts (e.g., Orders, Payments).
2. Refactor to ensure modules have no shared dependencies except via interfaces.
3. Add an anti-corruption layer to prevent leakage.
4. Extract the module as a separate service with its own database.

Real-World Examples

• Shopify runs a giant Rails monolith that is modular. They extract services only when necessary due to performance or team scaling.
• Uber started as a monolith and gradually decomposed into microservices as they grew globally.
• Segment wrote about their move from microservices to a modular monolith to reduce operational complexity (read more here).

Summary

The choice isn't binary: start with a modular monolith and add microservices when you hit clear scaling or team autonomy bottlenecks. Microservices are a complexity budget you spend when you must. For most teams, a well-structured modular monolith wins in terms of productivity and simplicity.

"Don't start with microservices. Start with a monolith, make it modular, and split it into microservices when you have a clear need." – Sam Newman, author of Building Microservices.

Further Reading

• Martin Fowler: MonolithFirst
• Segment: Goodbye Microservices
• Understanding Modular Monoliths