Microservices vs Monolith: Making the Right Architecture Decision

72% of companies that adopted microservices prematurely report increased complexity without proportional benefits. The microservices hype has led many teams to distribute their application across dozens of services when a well-structured monolith would have served them better, faster, and cheaper.

This guide provides an honest framework for choosing between monolithic and microservices architectures, including the hybrid approaches that often make the most sense for growing businesses.

Key Takeaways

• Start with a monolith unless you have a specific, proven need for independent scaling or deployment
• Team size is the strongest predictor of whether microservices will succeed: minimum 3 engineers per service
• The "modular monolith" pattern provides most microservices benefits without the operational overhead
• Migration from monolith to microservices should be incremental, extracting one service at a time

---

The Honest Comparison

Monolith Advantages

Microservices Advantages

Microservices Costs (Often Underestimated)

---

The Decision Framework

Decision by Team Size

Decision by Scaling Needs

Decision by Deployment Needs

---

The Modular Monolith: Best of Both Worlds

A modular monolith organizes code into well-bounded modules within a single deployable unit. Modules communicate through defined interfaces, not direct database access.

Architecture

Single Deployment Unit
+---------------------------------------------------+
|  [Orders Module]  [Inventory Module]  [Users Module] |
|       |                  |                 |        |
|       +------ Internal API Layer ----------+        |
|       |                  |                 |        |
|  [Orders DB]   [Inventory DB]    [Users DB]          |
|       |                  |                 |        |
|       +------ Shared Database Server ------+        |
+---------------------------------------------------+

NestJS Modular Monolith Pattern

// orders/orders.module.ts
@Module({
  imports: [
    InventoryModule, // Explicit dependency declaration
    UsersModule,
  ],
  controllers: [OrdersController],
  providers: [OrdersService],
  exports: [OrdersService], // Controlled public interface
})
export class OrdersModule {}

// inventory/inventory.module.ts
@Module({
  controllers: [InventoryController],
  providers: [InventoryService],
  exports: [InventoryService], // Only expose what others need
})
export class InventoryModule {}

Module rules:

1. Modules communicate through exported services, never through direct database access
2. Each module owns its database tables exclusively
3. Shared data is accessed through service methods, not JOINs across module boundaries
4. Module dependencies are explicit in the imports array

When to Extract a Module into a Service

Extract when:

• The module needs to scale independently (e.g., image processing, search)
• The module's deployment frequency differs significantly from the rest
• The module is maintained by a separate team
• The module has different technology requirements (e.g., ML model in Python)

Do NOT extract when:

• "It seems like it should be a service"
• You want a cleaner architecture (refactor the monolith instead)
• You have not identified a specific scaling or deployment need

---

Migration Strategy: Monolith to Microservices

The Strangler Fig Pattern

Gradually replace monolith functionality with microservices, routing traffic to the new service while the old code remains as a fallback.

Step 1: Identify the extraction candidate (highest scaling need or deployment friction)

Step 2: Build the new service alongside the monolith

Step 3: Route traffic to the new service via the API gateway

Step 4: Verify correctness by running both in parallel

Step 5: Remove the old code from the monolith

Data Migration Considerations

Recommendation: Start with a shared database during migration, then move to database-per-service once the service boundaries are proven.

---

Real-World Architecture Examples

eCommerce Platform

Modular Monolith (recommended for most):
- Product catalog module
- Cart and checkout module
- Order management module
- User accounts module
- Inventory module
All in one deployable unit, backed by one PostgreSQL instance.

Selective Microservices (for high-traffic stores):
- Search service (Elasticsearch, scales independently)
- Image processing service (CPU-intensive, different scaling)
- Payment service (PCI compliance boundary)
Everything else stays in the monolith.

ERP System (Odoo-style)

Monolith is the correct choice for ERP:
- Deep cross-module data relationships
- Complex business rules spanning modules
- Consistent reporting across all data
- Smaller concurrent user counts
- Transactional consistency critical

Odoo itself is a modular monolith: modules are installed/uninstalled,
but everything runs in one process with one database.

---

Frequently Asked Questions

Is our monolith holding us back?

Probably not, unless you have evidence of specific bottlenecks. If deployments are slow, invest in CI/CD. If one component needs to scale, extract it. If teams are stepping on each other, enforce module boundaries. Most "monolith problems" are actually code organization problems that microservices would not solve --- they would just distribute them.

How many microservices is too many?

A practical limit: no more than 3-5 services per engineer responsible for operations. A team of 5 engineers should own no more than 15-25 services. Beyond that, operational overhead dominates and engineering velocity drops. Many successful companies run 5-10 well-defined services rather than hundreds of nano-services.

Can we use different databases for different modules in a monolith?

Yes, this is the modular monolith approach. Each module can use a separate schema or even a separate database instance within the same deployable unit. This preserves data ownership boundaries without the operational cost of separate services. It also makes future extraction easier.

How does ECOSIRE approach this for clients?

We recommend starting with a modular monolith for most clients. Our Odoo implementation services use Odoo's modular architecture, and our custom development projects follow the NestJS modular monolith pattern. We extract services only when there is proven need for independent scaling --- typically search, file processing, or external integrations. See our DevOps guide for the full architectural philosophy.

---

What Comes Next

Architecture decisions are foundational. Once you have chosen your approach, invest in CI/CD automation for reliable deployment, monitoring for operational visibility, and API gateway patterns for managing service-to-service communication.

Contact ECOSIRE for architecture consulting, or explore our Odoo implementation services for ERP architecture that scales with your business.

---

Published by ECOSIRE -- helping businesses choose the right architecture for their stage of growth.