The microservices hype peaked around 2018–2020. Since then, a quiet counter-movement has emerged: companies like Shopify, Stack Overflow, and Basecamp have publicly credited their monoliths for their engineering efficiency. Here's the honest picture.
Start with a monolith
Almost every successful microservices architecture started as a monolith. The reason is fundamental: you can't draw the right service boundaries until you understand the domain. And you can't understand the domain until you've built the product and seen how it evolves. Premature decomposition creates wrong boundaries that are expensive to fix.
A well-structured monolith with clear module boundaries is easy to extract services from when the time comes. A poorly-structured monolith is a distributed monolith waiting to happen.
The real cost of microservices
Microservices solve real problems at scale: independent deployability, technology diversity, team autonomy, fault isolation. But they introduce an enormous operational tax. You need: service discovery, distributed tracing, network resilience (circuit breakers, retries, timeouts), distributed transactions, a service mesh, per-service CI/CD pipelines, and a platform team to manage the infrastructure.
For a team of 10 engineers, this overhead will consume 30–40% of engineering capacity. That's a tax most small teams can't afford.
When microservices are worth it
- Teams of 50+ engineers where Conway's Law makes a monolith hard to coordinate
- Dramatically different scaling requirements between domains (payments vs. search)
- Hard compliance boundaries that require data isolation
- Multiple client types needing different APIs (BFF pattern)
- Independent release cadences across business units
The modular monolith middle ground
The best architecture for most teams is a modular monolith: a single deployable unit with strict internal module boundaries enforced through code structure and linting rules. Modules communicate through defined interfaces, not shared database tables. When a module needs to scale independently, extract it. You'll extract the right service at the right time.
Database per service is non-negotiable (for microservices)
The most common microservices anti-pattern: multiple services sharing a single database. This creates tight coupling through the data layer — exactly what microservices are supposed to eliminate. If you're going microservices, each service owns its data. Cross-service data access happens through APIs, not joins.