Splitting one service into many is neither modern nor backward. It's a trade. You buy independent deploys, team autonomy and independent scaling — and you pay for them in network calls, operational surface, distributed debugging and latency. The correct number of services depends on how many teams you have and how complex your domain is. Everything else is fashion, and the fashion swings on a multi-year cycle. This tool lets you feel the trade-off directly, then tells you where your split actually lands.
Start at a monolith — one deployable — and split it. As services multiply, the calls between them multiply too. The gains rise; so do the costs. Set your team size and domain complexity, then drag the dial and read the fit: right-sized, over-split, or under-split.
Set your context above, then move the services dial to see where your split lands.
The industry keeps re-litigating this as a trend when it's a context-dependent choice. Three architectures sit on a spectrum, and each is the right answer somewhere. The middle one — the modular monolith — is the option most teams forget exists.
| Dimension | Monolith | Modular monolith | Microservices |
|---|---|---|---|
| Deployable units | One | One, with clean internal seams | Many, one per service |
| Deploy independence | None — everyone ships together | None yet, but split-ready | High — each team on its own cadence |
| Ops complexity | Low — one thing to run | Low — still one thing to run | High — per-service infra, on-call, tracing |
| Call latency | In-process (nanoseconds) | In-process (nanoseconds) | Over the network (milliseconds + retries) |
| Best team fit | 1–2 teams | 2–4 teams sharing a codebase | Many teams, each owning services |
| Failure mode | Big-bang releases; code turns to spaghetti | Module boundaries erode without discipline | Distributed monolith; ops sprawl; cascading failures |
Watch the pendulum swing. Each era over-corrects for the pain of the last — which is why "just do what everyone's doing now" is such poor guidance.
The right architecture falls out of two things: your team size and your domain. Choose the scenario that's closest to yours. You'll get a recommendation, the reasoning behind it, and the specific trap teams in that situation tend to fall into.
The same trade-off, lived out at different scales. Two are failures of judgement in opposite directions, one is the anti-pattern that looks like success, and one is the quiet, sensible middle almost nobody brags about.
Five engineers, twenty services, and a Kubernetes cluster nobody fully understands. They copied an architecture built for a thousand engineers and inherited its whole operational bill up front.
Tells
One enormous codebase, seventy teams, and a single release train everyone has to board. The architecture that got them here now blocks every team from shipping.
Tells
On the diagram it's a clean set of microservices. In reality they share a database and call each other synchronously, so a change to one forces a coordinated release of all of them.
Tells
One deployable, but organised into strict internal modules with clear interfaces. Fast in-process calls, one pipeline to run, and seams already drawn where a future split would go.
Why it works
Choosing the number of services is really a decision about your organisation — how your teams are shaped, where they need to move independently, and what operational load they can carry. That's the work we do with the engineering leaders we coach: turning an architecture debate back into a clear-eyed call about people, boundaries and cost.
Talk to us about coachingA new service should be earned by a real constraint — a team that needs autonomy, a component that needs its own scaling. Never adopted because it's the trend.
Your architecture ends up mirroring your org chart. Choose the boundaries and the team structure together, or the seams you draw on paper will rot in practice.
Services that must deploy together give you every cost of splitting and none of the benefit. If you can't deploy one alone, you haven't split — you've just added latency.