Monolith vs microservices: which architecture fits your product?
A monolith is a single application deployed as one unit, even if it is internally divided into modules. Microservices split the system into small, independently deployed services that communicate over the network. Microservices are often presented as the modern choice, but they are a response to specific scale and organisational problems, not an upgrade every product needs.
The short answer
Start with a well-structured monolith for almost every new product: it is faster to build, easier to test and simpler to run. Move to microservices when specific parts need to scale or deploy independently, or when several teams are slowing each other down in one codebase. Splitting too early adds network, data and operational complexity without solving a real problem.
Monolith vs Microservices at a glance
| Criterion | Monolith | Microservices |
|---|---|---|
| Deployment | One unit deployed together | Each service deployed independently |
| Development speed early on | Fast: one codebase, simple refactors | Slower: contracts between services |
| Scaling | Scale the whole app | Scale individual services |
| Data | One database, simple transactions | Database per service; consistency is harder |
| Debugging | Single process, straightforward tracing | Needs distributed tracing and central logs |
| Team structure | Suits one team or a few | Suits many teams owning separate services |
| Infrastructure | Simple hosting and pipelines | Containers, orchestration, service discovery |
| Failure modes | A bug can affect the whole app | Faults can be isolated, but networks add new ones |
Choose Monolith when
- You are building a new product, MVP or SaaS
- One small team, or a few developers, owns the codebase
- The domain is still changing and boundaries are unclear
- You want simple deployments, testing and debugging
- There is no dedicated platform or DevOps capacity
Choose Microservices when
- Several teams need to release independently without coordinating every deploy
- One part of the system has very different scaling needs from the rest
- Components need different languages or runtimes, such as a Python ML service
- Boundaries between business areas are well understood and stable
- You have the tooling and skills for monitoring, tracing and orchestration
The modular monolith
The best of both worlds for most products is a modular monolith: one deployable application with clear internal boundaries, such as billing, users and orders, that do not reach into each other's data. It keeps the simplicity of a single deploy while making it straightforward to extract a module into its own service later if there is a good reason.
What microservices really cost
Every service boundary turns a function call into a network call that can fail, time out or return stale data. You need retries, distributed tracing, centralised logging, versioned contracts and a plan for data that spans services. For large organisations those costs are worth paying; for a small team they mostly slow delivery.
Extracting services when it makes sense
In practice I often start with a Next.js or Node.js monolith on PostgreSQL and pull out a separate service only when there is a clear need, such as a background worker for heavy processing, a realtime server or a Python service for machine learning. That keeps the system simple while still allowing the right tool for specific jobs.
Frequently asked questions
Do monoliths scale?
Yes. A monolith can run as many identical instances behind a load balancer, with caching and read replicas. Plenty of large products run on monoliths.
When should I break up a monolith?
When independent deployment, scaling or team ownership becomes a real bottleneck, not just because the codebase is growing. Clear module boundaries make the split much easier.
Are serverless functions the same as microservices?
Not exactly. Serverless is a hosting model, and functions can belong to a monolithic codebase or to separate services. They share some operational challenges, such as tracing across calls.
Still deciding?
Tell me about your product, users and constraints, and I will recommend the option that fits, even if it is not the one I use most.
Ask for a recommendation