01 The Problem

A six-person engineering team at an early-stage startup reads that a company with thousands of engineers runs hundreds of microservices, and splits their monolith into twelve services because that's how you scale. Six months later: twelve repos, twelve deploy pipelines, twelve places a request can fail, and still six engineers. An incident at 2am now means figuring out which of twelve services is actually the problem, with no distributed tracing in place to help, and the same six people who used to grep one codebase for a bug now spend part of every week keeping twelve codebases' dependencies from drifting out of sync.

The problem they actually had, two people stepping on each other's changes in the same file, was never an architecture problem. It was six people working closely enough that their work kept colliding, and splitting the code didn't split the six people. They're still coordinating on everything, just now across twelve deploy pipelines instead of one, with twelve times the operational surface and none of the org structure that would have made twelve services make sense.

This is the actual decision. Not "can this be split," almost anything can. It's whether splitting matches how the org is actually organized, and whether the org has what it takes to run what a split creates.

02 What It Is

Whether to split a monolith into services isn't a technical question first, it's a Conway's Law question. Conway's Law says a system's architecture ends up mirroring the communication structure of the organization that builds it. It's usually stated as a warning, don't let your architecture accidentally mirror your org chart, but it's more useful read the other way: your architecture will mirror your org chart whether you intend it to or not, so the real question is whether you're planning for that or getting surprised by it. Split a system into services that don't match how your teams are actually organized, and you get services owned by nobody in particular, or a "boundary" two different teams both have to touch for every feature, still coupled, now with a network call in between.

The forcing function for splitting is team size hitting the point where one codebase, one deploy pipeline, actually gets in the way, not a request-per-second number. And splitting requires operational maturity the team may not have yet: someone owns monitoring across N services instead of one, someone's on call for N things instead of one, and deployment tooling has to make deploying twelve things routine, not an adventure each time.

In Plain Terms

A family of four sharing one car works fine right up until everyone's schedule stops overlapping enough to coordinate around one vehicle. The fix at that point is buying a second car for the two people whose schedules actually conflict, not because the family grew, but because two specific people now need to be in two places at the same time. Buying four separate cars before anyone's schedules conflict just means four car payments, four insurance policies, and four things to maintain, for a problem nobody had yet.

03 How It Works

Rendering diagram…

Rendering diagram…

04 Trade-offs

	Splitting before the org is ready	Splitting when team size forces it
What drives the decision	A blog post, a resume line, "this is how it's done"	Multiple teams actually blocked on each other in one codebase
Operational readiness	Monitoring, on-call, and deploy tooling built for one thing, now stretched across many	Built out alongside the split, or already in place before it happens
Service boundaries	Drawn along technical layers, since no team structure exists yet to draw them along	Drawn along team ownership, so each service has one clear owner
What actually improves	Nothing; the same small team now coordinates across more moving parts	Teams stop blocking each other, because the split matches how they already work

05 Where You'll Actually See This

Both case studies in this library are deliberately scoped as a single service, and that's itself an example of the right call for their context: a scaffold article demonstrating one pattern doesn't need twelve services and an on-call rotation to make its point.

This article is the "when." Microservices architecture is the "how," the actual mechanics of what splitting costs: network calls where function calls used to be, data ownership split across databases once one becomes several. Read that one for what a split actually does to your system. Read this one for whether you should do it at all.

How to reason about it

When asked whether a system should move to microservices, don't answer with anything about the system's architecture first. Ask about the team: how many people, how many teams, are they actually blocked on each other today, and does the org have the on-call and monitoring muscle to run more than one deployable thing. A technically clean service boundary drawn for a team of six that doesn't have the ops maturity yet is a worse outcome than staying a monolith for another year.

06 Quick Check