Services solve people problems first
The honest reason to split a system is ownership: two groups who ship on different rhythms, with different risk profiles, stepping on each other’s deploys.
A boundary lets each group move at its own speed. That’s the benefit — autonomy — and it accrues to teams, not to code. If one team owns everything, a split mostly buys them network calls between their own functions.
Every boundary has a bill
The costs arrive quietly and all at once:
- A function call becomes a network call that can fail half-way.
- One log file becomes tracing infrastructure.
- One deploy becomes a compatibility matrix.
- “Where does this happen?” becomes a research task.
None of these are arguments against services. They’re the price tag — and the price is fixed even when the benefit isn’t.
The modular monolith is a real destination
The middle path deserves more respect than it gets: one deployable, strict internal modules, boundaries enforced by the build rather than by the network.
You can draw every line a service architecture needs without paying the distributed-systems bill — and harden a line into a service later, when a team actually needs the autonomy.
Most systems we’re hired to rescue should have stopped here.
Signs a split is genuinely due
We look for evidence, not vibes:
- Two parts of the system need conflicting scaling profiles.
- A component’s deploys keep endangering an unrelated one.
- A team is measurably blocked waiting on another’s release train.
- A piece needs an isolation boundary for compliance or risk.
Two or more of these, sustained for months — split, and split only there.
Extract like a surgeon, not a demolition crew
When the time comes, the winning move is boring: pick one seam, extract one service, run it in production long enough to trust your tooling, then decide again. Big-bang decompositions convert a working monolith into a distributed rewrite with no rollback plan.
The takeaway
Size the architecture to the organization you have, not the one in the conference talk. Small teams win with small systems — and the best distributed systems are the ones that grew a boundary at a time, each one paying rent.