From Monolith to Modular Architecture: When to Split a Backend

Split the code before splitting the network

A monolith becomes painful when ownership and dependencies are unclear, not simply because it is one deployable unit. Explicit modules, stable interfaces, and local data ownership expose those problems while they are still cheap to fix.

Earn the operational cost

A separate service brings independent scaling, but also deployment coordination, network failure, distributed tracing, and more complicated local development. The boundary should solve a real pressure point.

I would extract when a module has a clear owner, a meaningful scaling or isolation need, and a contract that can survive independent change.

Architecture should make the next change safer, not merely make the diagram more impressive.

Boundaries before services

I would start by making module dependencies explicit: identity, billing, inventory, notifications, and reporting should not reach into one another's tables casually. A module exposes commands and queries through a small interface, even when all modules share one process and database.

flowchart LR
  A[Web application] --> B[Orders module]
  A --> C[Inventory module]
  B --> D[Inventory interface]
  B --> E[Billing interface]
  C --> F[(Inventory tables)]
  D --> C
  E --> G[Billing module]

Migration path

A good modular monolith makes extraction boring. Replace an in-process interface with an adapter, introduce a durable event or RPC contract, move ownership of the data, and compare behavior before removing the old path. The sequence matters because moving code and moving data are separate risks.

export interface InventoryPort {
  reserve(input: ReserveInventory): Promise<Reservation>;
}

export function createOrder(inventory: InventoryPort, input: OrderInput) {
  return inventory.reserve({ orderId: input.id, lines: input.lines });
}

When not to split

If two modules change together, share a transaction, and have one operational owner, a network boundary may add failure without adding independence. Split for a clear reason: separate scaling, isolation, ownership, deployment cadence, or regulatory boundary. Otherwise, keep the boundary in code and let the system stay simple.