Monolith vs Microservices
IntermediateA monolith packages an entire application as one deployable unit; microservices split it into many small, independently deployable services. Monoliths are simpler to build, test, and deploy, and are the right default for most new projects. Microservices offer independent scaling and team autonomy but add heavy operational and distributed-systems complexity. The choice is really about organisational scale and operational maturity, not just technology — and there is a strong middle ground: the modular monolith.
Think of one big shop versus a mall of specialist stores
A monolith is one large department store: everything under one roof, one manager, easy to walk between sections. A microservices system is a mall of independent specialist stores, each with its own staff, hours, and supplier. The mall lets each store scale and change on its own, but now you need shared infrastructure — security, plumbing, a directory — and coordinating a mall is far more work than running one shop. You open a mall when one shop can no longer serve the crowd.
Step by Step
Key Concepts
Independent Deployability
The core microservices benefit: each service ships on its own schedule. It enables team autonomy but requires mature CI/CD, versioned APIs, and backward compatibility between services.
Data Ownership
In microservices, each service owns its database and no other service touches it directly. This is what enables independence — and what makes cross-service transactions hard, requiring sagas.
Modular Monolith
A single deployable with strong internal boundaries between modules. It delivers monolith simplicity while keeping clean seams, making a future split to microservices far easier if needed.
Distributed Monolith
The anti-pattern where services are split physically but remain tightly coupled — they must deploy together and share a database. You pay microservices costs and get none of the benefits.
Key Facts
- Most new projects should start as a well-structured monolith; premature microservices add complexity a small team cannot afford.
- Microservices solve an organisational scaling problem (many teams shipping independently) more than a technical one — a single team rarely needs them.
- The worst outcome is a distributed monolith: services that cannot deploy independently, giving you all the operational cost and none of the autonomy.
Real-World Applications
A startup MVP
A small team should build a modular monolith: fast to develop, easy to deploy and debug, and cheap to run — extracting a service only when a specific part needs independent scaling or ownership.
A large organisation
A company with dozens of teams uses microservices so each team owns and ships its service independently, avoiding the coordination bottleneck of everyone deploying one giant monolith.
Frequently Asked Questions
What is the difference between a monolith and microservices?
A monolith is a single deployable application where all modules live together and usually share one database, communicating via in-process calls. Microservices split the application into many small, independently deployable services, each owning its own data and communicating over the network. Monoliths are simpler to build and operate; microservices offer independent deployment and scaling at the cost of distributed-systems complexity.
When should I use microservices instead of a monolith?
Choose microservices when organisational scale demands it — many teams needing to build, deploy, and scale their parts independently — and when you have the operational maturity (CI/CD, observability, on-call) to run many services. For most new projects and smaller teams, a well-structured monolith is simpler, cheaper, and faster to evolve.
What is a modular monolith?
It is a single deployable application with strong, well-defined internal boundaries between modules. It gives you the operational simplicity of a monolith while keeping clean seams, so individual modules can be extracted into separate services later if the need arises. It is often the best starting point and avoids premature microservices complexity.
What is a distributed monolith?
It is an anti-pattern where an application is split into separate services physically, but they remain tightly coupled — they must be deployed together, share a database, or depend on each other synchronously. You incur all the operational cost and complexity of microservices while getting none of the independence, making it worse than either a clean monolith or true microservices.