About Microservices vs Monolith

Default to monolith; when to split; the modular-monolith middle path. Part of the DevTools Surf developer suite. Browse more tools in the Info / Guides collection.

Use Cases

• Startup founders deciding on initial architecture for a new product
• Engineering leads evaluating when to split a growing monolith
• Platform teams designing bounded contexts for service extraction
• CTOs assessing team structure alignment with architectural boundaries

Tips

• Start with the 'default to monolith' argument before considering splitting
• Check the modular monolith section for the pragmatic middle ground
• Review the splitting criteria to know when microservices actually help

Fun Facts

• Martin Fowler and James Lewis coined the term 'microservices' in a March 2014 blog post, though the architectural style had been practiced at Netflix and Amazon since 2009.
• Amazon's 2002 mandate from Jeff Bezos — that all teams must communicate through service interfaces — is widely considered the origin story of microservice architecture.
• A 2020 study by InfoQ found that 63% of organizations using microservices reported increased operational complexity, often underestimating the 'distributed systems tax.'

FAQ

Should I start with microservices?

Almost never. The overhead (service discovery, distributed tracing, API versioning, data consistency) is enormous. Start monolithic; split when you hit team-scaling limits.

When does splitting make sense?

When services have independent scaling needs, different rate-of-change, or cross different teams. Premature splitting is a common and expensive mistake.

What's a modular monolith?

A monolith with strong internal boundaries (module per domain, no cross-module imports). Gets most microservice benefits without the operational cost. Increasingly popular alternative.

What about distributed monolith?

The failure mode — services that call each other synchronously for every request. You get microservice complexity AND monolith coupling. Worst of both worlds.