Monolith vs microservices
A monolith is one application deployed as a whole. Microservices split it into small services that talk over the network. The second solves problems of large organisations; a small team usually pays its costs without having the problems.
Which fits a small team?
Monolith
- Simple to build, test and run
- One place to debug
- Cheap to host
- Splitting later is possible
Microservices
- Teams deploy independently
- Scale parts separately
- Needs monitoring and DevOps skills
- Slower to start, harder to debug
What changes when you split
A function call becomes a network call that can be slow or fail. Data that lived in one database is spread across several, so a change that touched one transaction now needs coordination. You also need tracing, deployment pipelines and versioning between services.
When splitting pays off
Separate services help when different teams need to release on their own schedule, when one part needs to scale far beyond the rest, or when parts need different technology. These are signs of size, not of ambition.
A practical middle path
Build a modular monolith: one deployable application with clear internal boundaries between modules. When a module truly needs to leave, the boundary is already there.
Questions
Are microservices faster?
Not by themselves. Calls over a network are slower than function calls; the gain is independent scaling and releases, not raw speed.
How big should a service be?
Sized around one business capability that one team can own, not as small as possible.
Can I start with a monolith and move later?
Yes, and it is the common advice, provided you keep the modules separate inside the code.
What is a distributed monolith?
Services that must be deployed together because they depend on each other so tightly: all the cost of microservices with none of the independence.