Microservices vs. monolith: what's right for your SaaS
Microservices or monolith for your SaaS product? Why a modular monolith is usually the better start, and the signals that tell you it is time to split.
In short: For most SaaS products, a well-structured modular monolith is the right starting point: one application, one deployment, one database, with clear boundaries between business modules. Microservices pay off when several teams need to ship independently, or when individual parts have very different requirements for scaling, technology or availability. If you modularise cleanly, you can extract specific modules later.
How the two approaches differ
A monolith is an application that is built, tested and deployed as a whole. All features share one process and usually one database. Calls between modules are plain function calls.
With microservices, the system is split into independent services that each own their data and communicate over the network, through HTTP APIs or message queues. Each service can be deployed and scaled on its own.
The decision is mostly about organisation: microservices move complexity out of the code and into operations.
What microservices really cost
Distributed systems are hard
Network calls can fail, be slow or arrive twice. Every service needs retry logic, timeouts and a plan for partial outages. Data that used to be written in one transaction is spread across several databases, and consistency then has to come from patterns like sagas or outbox tables.
Operations and observability
Instead of one application, you run many. Each needs a deployment pipeline, logging, metrics and alerts. Tracing an error across services requires distributed tracing, for example with OpenTelemetry. Our article on monitoring and observability explains how to set that up.
Speed of development early on
A feature that touches three services needs three coordinated changes, versioned interfaces and aligned releases. For a small team still searching for product-market fit, that is a real drag.
The modular monolith as a middle path
A modular monolith ships as one application but is internally divided into clearly separated modules, such as billing, user management and reporting. Each module has a defined interface, and other modules do not reach directly into its tables or internal classes.
That discipline brings many of the benefits of microservices without the operational overhead. Teams can work on separate modules, boundaries stay visible, and dependencies can be checked with tooling. In TypeScript projects, a monorepo with separate packages helps; see our post on monorepos with Turborepo.
Other foundational choices that are hard to reverse later, like multi-tenancy and the data model, are covered in our article on SaaS architecture decisions.
When it is time to split
A few clear signals suggest that extracting a service is worth it:
- Several teams regularly block each other's releases.
- One part of the system has a very different load profile from the rest, for example image or video processing, and needs to scale independently.
- A module needs a different technology, such as Python for machine learning next to a Node.js backend.
- An area has stricter availability or security requirements and should run in isolation.
If none of these apply, splitting is usually premature. When it does make sense, extract the module causing the most pain first rather than everything at once. For background jobs with spiky load, a serverless architecture can be a lighter alternative to a full service.
Frequently asked questions (FAQ)
Does a monolith scale at all?
Yes, much further than many people assume. A monolith scales horizontally by running several instances behind a load balancer. Bottlenecks usually sit in the database, and microservices have those too.
Is moving from a monolith to microservices expensive later?
For a tangled monolith, yes, because everything is connected to everything. For a modular monolith with clear interfaces, a module can be extracted in a fairly targeted way. The real work is the modularisation, done up front.
How many developers do you need for microservices?
There is no fixed number. As a rule of thumb, each service should have a team that owns and runs it. When a small team looks after many services, the overhead usually wins.
Do microservices require Kubernetes?
No. Kubernetes is common, but managed container services or platforms like Fly.io and Render can run services too. Kubernetes makes more sense with many services and a team experienced in running it.
Conclusion
In practice, team size and product stage settle the architecture question. A modular monolith keeps both paths open, and with clean modules you can decide on microservices when there are real reasons to.
If you are planning the architecture of a new SaaS product, talk to us about web development.
Related posts
- Building a SaaS Product: Architecture Decisions You Can't Undo
Multi-tenancy, data model, authentication and hosting: the SaaS architecture choices that are hard to reverse, and how to make them well from the start.
- CI/CD pipelines for web applications: a practical guide
How to set up a CI/CD pipeline for a web application: build, tests, preview environments, deployment and rollback. With tool choices and common pitfalls.
- Serverless Architecture: When It Makes Sense and When It Doesn't
When serverless with AWS Lambda and similar saves cost and effort, where cold starts, time limits and lock-in cause trouble, and what the alternatives are.
- Database selection: PostgreSQL, MongoDB or something else?
PostgreSQL, MongoDB, MySQL, Redis or SQLite: which database fits your web application? A practical comparison with clear criteria for the decision.