CodeParkFor a team of six on a new product, a monolith is usually the right start.
Microservices split the system into many small services. They give you:
- independent deploys
- independent scaling
- fault isolation, so one failing service does not take down the others
- freedom to pick a different technology per service
- many teams can work without getting in each other's way
The price is the complexity of a distributed system:
- Network calls can fail, and they add latency.
- Data is spread across services, with no transactions across services.
- Debugging is harder and needs tracing.
- You need much more infrastructure and operations work.
A monolith is one deployable application. It is simple to develop, test, deploy and debug. Calls stay inside one process, and transactions are local. Its problems appear as it grows: slow builds, risky deploys, and teams blocking each other.
Why start with a monolith? On a new product, the domain boundaries are still unclear. If you draw service lines in the wrong place, moving them later is costly. Martin Fowler's "monolith first" advice says: build a well-modularised monolith, and split out services later when a real need appears.
- Microservices give independent deploys, independent scaling and team autonomy.
- Their cost is network failures, distributed data and more operations work.
- A monolith is simple, fast to change and has local transactions.
- A small team and an unclear domain favour starting with a monolith.
- Split out services later, along boundaries that have proven themselves.