Monolith vs microservices
The question sounds architectural. In practice it is about how many teams need to ship without asking each other for permission.
The short answer
Start with one well-organised application, and split into services only when separate teams are blocking each other or one part genuinely needs to scale on its own.
Microservices are a solution to a coordination problem. If you have one team of six, you do not have that problem yet, and splitting will slow you down while looking modern.
The middle option is the one most teams should take. Keep one deployable application, but organise it in clear modules with real boundaries. That preserves the option to split later, at the seams you have already found.
Side by side
Compared on operational reality rather than on diagrams.
| Dimension | Monolith | Microservices |
|---|---|---|
| Deploying a change | One release, everything together | Each service on its own schedule |
| Teams shipping in parallel | Coordination grows painful past a point | Independent, which is the whole point |
| Finding a bug | One log, one stack trace | A trace across several systems |
| Changing shared data | One migration, applied once | Coordinated change across owners |
| Scaling | Scale the whole thing | Scale the busy part only |
| Partial failure | Usually all up or all down | Normal, and must be designed for |
| Operational skill needed | Moderate | High, and permanently staffed |
| Sensible trigger | Almost every new build | Several teams, or one part with different load |
- NetworkA function call becomes a request
- RetriesEvery call can now fail halfway
- TracingOr debugging becomes guesswork
- VersioningContracts between teams
- On callMore systems, more pagers
Every box here is work you did not have before. Independent teams have to be worth all five.
Monolith
Where it wins
- One place to look when something is wrong, which shortens most investigations to minutes.
- Changing data that several features share is one migration rather than a negotiation.
- Local development is simple, so a new engineer is useful in days.
- Correctness across features is easier, because the work can happen in a single transaction.
Where it hurts
- Past a certain team size, everyone waits on the same release, and the queue becomes the bottleneck.
- One heavy feature forces you to scale the entire application to serve it.
- Without discipline the modules blur together, and eventually every change touches everything.
- A bad deployment takes the whole product down rather than one part of it.
Microservices
Where it wins
- Teams release on their own schedule without waiting for anyone else's testing.
- The part under heavy load scales alone, which can be the difference during a spike.
- A team can choose the right tool for one job without imposing it on everybody.
- Clear ownership makes it obvious who fixes what at two in the morning.
Where it hurts
- Every call across the network can fail, time out, or arrive twice, and your code must handle all three.
- Debugging needs tracing across systems, so you must build that before you need it.
- Data spread across services makes consistency an ongoing design problem rather than a database feature.
- You need people who can run this permanently. Without them you have a distributed system nobody understands.
How to choose
- Choose a monolith for anything new. You do not yet know where the boundaries belong, and guessing wrong is expensive to undo.
- Choose a modular monolith as the default for a growing product: one deployment, hard internal walls, and the option to split.
- Choose microservices when several teams are genuinely blocked by each other's release schedule.
- Choose microservices for one component whose load is nothing like the rest, such as report generation or video processing.
- Choose to split one service at a time. Extracting the noisiest part and living with it for a quarter teaches more than any plan.
- Choose neither pattern as an identity. The architecture is not the product, and users have never once cared.
Multi-tenant systems we have shipped
Questions engineering leaders ask
01How do we know it is time to split?
Look at what is slowing releases down, not at the size of the codebase. The honest signals are teams waiting on each other's testing, one component needing very different capacity, and a release everyone fears. Line count is not a signal, and neither is a conference talk.
02What is a modular monolith?
One application with hard walls between its parts, so each one talks through a defined interface instead of reaching inside another. You get most of the team benefits with no network in the middle. It is also the cheapest way to find the real seams before you commit to splitting.
03Can we go back to a monolith?
Yes, and teams do it more often than the internet suggests. Merging services back is usually easier than splitting them was, because the boundaries already exist in the code. Treat a reversal as a legitimate outcome rather than a defeat: the goal is shipping software, not maintaining a diagram.
04Does microservices architecture improve reliability?
Only if you design for partial failure. Skip that and it makes things worse. With many services, something is always unwell, so the system has to keep working while a piece is down. A monolith fails less often but takes more with it. That is a different risk, not a worse one.
05Our system is a mess. Will splitting it fix that?
No, and it usually makes it worse. A tangled monolith becomes a tangled set of services, with the same mess plus network calls between the messy parts. Clean up the walls inside the application first. If that cannot be done, the problem is ownership and knowledge. Neither gets fixed by moving code onto more servers.
