An honest decision tree, not a quiz
Most “monolith vs microservices” content is sales material — for a framework, a platform, or a consultancy. This walks through the constraints that actually decide the answer: team shape, domain clarity, operational maturity, and whether you’re already running a distributed monolith. One question at a time. No score, no leaderboard, no gradient.
How the tree thinks
- Q1–Q2 catch the distributed monolith. The most common failure mode I see isn’t “they picked microservices when a monolith would do” — it’s “they have microservices in name but a shared database in fact”. That’s worse than either pure choice, so it’s the first thing to surface.
- Q3 is about coordination cost, not size as a virtue. Eight is a rough heuristic: below that, the cost of coordinating around one codebase is lower than the cost of operating multiple services. Above that, the calculus starts to flip.
- Q4–Q5 only matter if scaling and ownership line up. Different scaling profiles inside the same team is a job for a thread pool, not a service boundary. Different scaling profiles across teams that already own the relevant domains — that’s a real reason.
- Q6 is the one most teams skip. Microservices is an operational discipline first. If you don’t have tracing, deployment automation, service discovery and a working on-call rotation, splitting the codebase will not make any of those easier.
- Q7 is about whether you can draw the lines. Bounded contexts that are still moving make for service boundaries that are still moving — and moving a service boundary in production is the single most expensive refactor in the playbook.
Caveats
This tree is intentionally short. It will not catch every situation (regulatory isolation, multi-tenant fan-out, language polyglot needs, acquisition integration), but it will catch the cases where a team is about to make the most common monolith-vs-microservices mistake. Treat the outcome as a strong prior, not a verdict.