How it works
In a monolith, the web pages, API, background jobs and business logic live in one project and ship together. Calls between features are ordinary function calls, a single database transaction can cover several features, and there is one thing to build, test, deploy and monitor. Rails, Laravel and Django apps, and a Next.js app with its API routes, are typical monoliths.
Problems appear with size: a big codebase gets slow to build and risky to change, and one busy feature cannot be scaled on its own. A modular monolith, with clear boundaries between features inside the one codebase, keeps most of the simplicity while leaving a later split possible. Some well-known teams have moved back from microservices to a monolith after finding the overhead too high.
Monolith pros and cons
Pros
- Simple to build, test, deploy and debug
- Fast calls and easy transactions across features
- One codebase that a small team can understand
- Cheaper to host and monitor
Cons
- Large codebases get slow to build and risky to change
- One feature cannot be scaled or deployed on its own
- One bad bug or deployment can take everything down
When to use Monolith
Pick it when
- New products, startups and small to medium teams
- Most business apps, stores and SaaS products
- You are still learning where the natural boundaries lie
Skip it when
- Many independent teams must release separately and often
Monolith vs the alternatives
Related terms
More in Rendering and architecture
Architecture