A monolith is one application deployed as a unit. Microservices split a system into many small services that talk over the network. The second sounds modern; the first is usually quicker and cheaper to build and operate.
What microservices cost you
- Calls between parts become network calls, which are slower and can fail.
- Data is spread across services, so keeping it consistent is harder.
- Each service needs deploying, monitoring and securing.
- Debugging a problem means following a request across several systems.
When they are worth it
- Many teams that must ship independently.
- Parts with very different scaling or reliability needs.
- A proven, stable boundary between parts of the business.
The middle way
Build a modular monolith: one deployable application with clear internal boundaries, so the code is organised as if the parts could be separated. If one of them later needs to be carved out, the seams are already there.
Premature splitting is a common way for a small project to burn its budget on infrastructure instead of the product. As a solo developer I choose the simplest structure that will carry the product for the next stage and keep the boundaries clean enough to change it later.