advanced

Modular monolith

Keep one deployment while enforcing module boundaries, ownership, and dependency rules so future extraction remains possible.

Modular monolith keeps one deployment while enforcing module boundaries, ownership, and dependency rules—often via packages, arch lint, or domain folders. Teams gain clear seams for future extraction without paying network partitions today. Public module APIs mirror microservice contracts in miniature.

On interviews: describe how you prevent modules from importing each other's internals. Compare with distributed monolith anti-pattern.

Common pitfalls: boundaries only on paper; shared database tables coupling modules; synchronous in-process calls pretending to be services without contracts.

The trade-off is flexibility versus complexity—know when the simpler path is enough.

Checklist:

  • Published module APIs are narrow and stable.
  • Forbidden imports enforced in CI.
  • Data ownership per module documented.
  • Extraction playbook exists before splitting.