Monolith First

An approach where you start with a single deployable application and extract services later, only when there's a real reason to.

Monolith first means starting a new project as a single deployable application instead of jumping straight into microservices. You extract services later, when you have a concrete reason to: independent scaling, separate team ownership, or different deployment cadences.

The term was popularized by Martin Fowler. His observation: almost every successful microservice system started as a monolith that grew large enough to break up, while almost every system built as microservices from scratch ended up in serious trouble. Splitting a system into services before you understand its boundaries usually produces a distributed system with arbitrary seams that don't match how the domain actually works.

The reason it works is that boundaries are hard to get right upfront. You don't know which parts of your system will change together until you've watched it evolve. A monolith lets you move those boundaries as you learn. Moving a function call across a network is much harder than moving it across a package.

Monolith first doesn't mean "write everything in one big package." It means deploy as one unit, but design with clear bounded contexts, a domain layer that doesn't know about HTTP or databases, and dependencies pointing inward (Clean Architecture). When the time comes to split, the boundaries are already there. Switching from a Modular Monolith to microservices becomes a deployment decision, not a rewrite.

Some teams may in fact need separate services from day one because of isolation due to regulations, different scaling needs, or organizational structure that makes a shared codebase impractical. But these are the exceptions. For most projects, those constraints don't apply. Start with a monolith, ship something, and let the pain of growing it tell you where to cut.

When the time comes to extract, the Strangler Pattern is one of the safer migration paths.