When not to use microservices

Key points

• Small team, one product, a domain you are still learning? Stay monolithic. You will move the boundaries three times before they are right.
• Microservices need platform muscle: a pipeline per service, automated deploys, central logs, tracing, on-call. Without it, chaos.
• The worst outcome is a distributed monolith: services that must be released together. All the latency, none of the independence.
• Splitting the shared database is the hard half. If services still read tables owned by another service, nothing was split.
• Good reasons to split: different scaling profiles, different release cadence, team autonomy, hard isolation for compliance or blast radius.
• Best path for most teams: modular monolith first, honest module boundaries, then extract the one module that hurts.

Split a service when a boundary is proven and painful, never because it is fashionable.