Modular Monolith vs Microservices

The microservices vs monolith debate often misses the most practical option for product teams: the modular monolith.

Why Modular Monolith First

A modular monolith gives you:

• Single deployment unit — no distributed tracing complexity on day one
• Feature module boundaries — enforce isolation through code structure, not network calls
• Clean Architecture layers — domain logic stays testable and framework-agnostic
• Future extraction path — well-bounded modules can become services when metrics demand it

When Microservices Make Sense

Extract to microservices when you have evidence:

• Independent scaling requirements per module
• Different team ownership with conflicting release cycles
• Technology heterogeneity that justifies separate runtimes

Without these signals, microservices add operational overhead without proportional benefit.

Module Structure That Scales

Each feature module should own:

feature/
  domain/       → entities, repository interfaces
  application/  → use cases, DTOs
  infrastructure/ → persistence, external adapters
  presentation/ → routes, controllers, UI

Shared kernel modules (RBAC, notifications, audit logging) live in a platform layer — consumed by features, never coupled to feature-specific domain logic.

Practical Takeaway

Start with a modular monolith. Invest in module boundaries and shared enterprise frameworks. Extract services when operational metrics — not architecture fashion — justify the split.