Monolith vs Microservices
A trade of deployment independence against distributed-systems complexity, decided by team topology far more often than by technology.
Microservices buy one thing that matters: independent deployability, and with it independent scaling and independent team ownership. They charge for it in network calls that can fail, transactions that can no longer be atomic, debugging that now requires distributed tracing, and an operational surface that multiplies.
If you have three teams, you are paying that bill for a benefit you cannot yet collect. The default for most systems is a well-structured modular monolith, with services extracted where a specific and articulable pressure exists — a component with a genuinely different scaling profile, or one that a separate team needs to release on its own cadence.
The strongest predictor of whether microservices will help is not system size. It is whether the organisation is already partitioned along the same lines the services would be.