When consulting on software architecture for enterprise clients, the first question is almost always: "Should we go with microservices right from the start?" Our short answer is no. The long answer is this article.
The Hidden Cost of Early Microservices
During our 2024 HRM project, the team initially wanted to split 12 bounded contexts into 12 separate microservices. We convinced them to consolidate into a modular monolith instead. That decision saved four months of infrastructure setup, two full-time DevOps engineers, and allowed the team to focus on payroll logic rather than debugging service meshes during the first six months.
When Should You Separate?
We set three explicit criteria before turning a module into a standalone service: (1) distinct traffic scale — e.g., the Notifications module handling 100x requests compared to the rest, (2) independent deployment needs — typically when the module team exceeds 8–10 engineers, (3) distinct compliance or security boundaries — e.g., restricting PCI-DSS scope for a Payment module.
Real-World Pattern: Clear Boundaries, Single Deploy
In production code, we enforce module boundaries using ArchUnit (Java) or Conventional Commits + custom linters (.NET, Node). Each module resides in its own folder and cannot import classes from other modules directly — all interactions go through public interfaces. Database schemas are also partitioned in PostgreSQL. When separation is needed, replacing the internal interface with an HTTP client takes minimal effort.
Pragmatic Conclusion
A modular monolith is not a 'monolith in disguise' — it is a serious architectural commitment with significantly lower operational overhead than microservices. Start here. If after 18 months you still have no need to split, you probably never will.
