06-22-2026, 07:26 AM
Unpopular opinion: monorepos are usually the right choice and the push toward microservices was overcorrection for most teams.
The promised benefits of microservices (independent deployment, technology flexibility, team autonomy) require a level of infrastructure maturity and team size that most companies don't have. What you get instead: complicated inter-service communication, distributed tracing headaches, deployment coordination, and the classic "making a simple change now requires touching five repos."
A well-structured monolith with clear module boundaries is easier to reason about, easier to test, and often faster to develop and deploy. You can still run it as multiple processes if scaling requires it. You don't need to solve distributed systems problems until you actually have scaling problems that require distributed systems.
The companies that actually benefit from microservices (Netflix, Spotify, Amazon) have thousands of engineers. If your engineering org is under 50 people, you probably don't.
The promised benefits of microservices (independent deployment, technology flexibility, team autonomy) require a level of infrastructure maturity and team size that most companies don't have. What you get instead: complicated inter-service communication, distributed tracing headaches, deployment coordination, and the classic "making a simple change now requires touching five repos."
A well-structured monolith with clear module boundaries is easier to reason about, easier to test, and often faster to develop and deploy. You can still run it as multiple processes if scaling requires it. You don't need to solve distributed systems problems until you actually have scaling problems that require distributed systems.
The companies that actually benefit from microservices (Netflix, Spotify, Amazon) have thousands of engineers. If your engineering org is under 50 people, you probably don't.