BYD TechThe short answer
A monolith is a single application that is built and deployed as one unit. Microservices split a system into many small services that run and deploy separately and talk over the network. Microservices help large organizations with many teams move independently, but they add real cost: more infrastructure, harder debugging and more ways to fail. Most startups should begin with a well-organized monolith, split into clear modules, and extract a service only when there is a concrete reason.
Key points
- Monolith: one codebase, one deployment. Simple to run and change.
- Microservices: many services, deployed separately. Built for many teams.
- Microservices solve organizational problems more than technical ones.
- Start with a modular monolith: clear boundaries inside one application.
- Extract a service when a specific part needs to scale or deploy on its own.
Side by side
| Monolith | Microservices | |
|---|---|---|
| Deployment | One application | Many services, each on its own |
| Calls between parts | Function calls in memory | Network requests |
| Debugging | One place to look | Tracing across services |
| Infrastructure | Simple | Service discovery, monitoring, many pipelines |
| Team fit | One or a few teams | Many independent teams |
| Scaling | Scale the whole application | Scale each service separately |
Why most startups should start with a monolith
Martin Fowler’s "Monolith First" argues that almost every successful microservice system started as a monolith that grew too big, and that projects which began with microservices often ran into trouble. The reason is simple: you cannot draw good boundaries between services until you understand the product, and early on, nobody does.
- Changes that touch several parts happen in one place, in one release.
- One database keeps data consistent without extra machinery.
- Hosting and monitoring stay cheap and simple.
- A small team spends its time on the product, not on plumbing.
The middle ground: a modular monolith
The real risk with a monolith is not that it is one application. It is that, without discipline, everything becomes tangled with everything else. A modular monolith keeps the simplicity of one deployment but organizes the code into modules with clear boundaries: billing, accounts, orders, each with its own responsibilities and interfaces.
If a module later needs to become its own service, those boundaries make the extraction straightforward.
When microservices start to make sense
- Many teams are stepping on each other in one codebase.
- One part has very different scaling needs from the rest.
- One part needs a different technology, such as heavy data processing.
- One part must be deployed far more often, or isolated for security.
Each is a concrete reason. "It is how big companies do it" is not one. Splitting too early is a common source of technical debt of a different kind: complexity nobody needed.
In practice
A first product is usually best served by one well-organized application, one database and standard hosting. How the pieces fit is in What is a tech stack?. In web app development the code lives in your GitHub, so the structure is yours to grow.
Sources
Checked when this guide was written.
