Two shapes
A monolith packages all features into a single deployable application that shares one codebase and usually one database. Microservices split those features into many small services that deploy and scale independently and talk over the network.
What microservices buy
- Independent deploys so one team ships without coordinating the whole app.
- Independent scaling so a hot feature gets more machines without scaling everything.
- Fault isolation so one failing service need not take the rest down.
What they cost
That freedom is not free. You take on network calls that can fail, distributed data that is hard to keep consistent, and far more operational complexity in deployment, monitoring, and tracing.
A sensible default
Most teams are better off starting with a well structured monolith and splitting out services only when a clear scaling or team boundary demands it. Premature microservices add distributed systems pain before you have the scale to need it.
Key idea
Start with a clean monolith and extract microservices only when scale or team boundaries justify the cost.