Should You Split That Into Microservices? Ask These 5 Questions First

Split into microservices only when you can point at concrete drivers: measurably different scaling needs, teams blocking each other in one release process, a data boundary you can draw cleanly, or a real need for independent failure or release. You also have to afford the platform tax. With two or three yes answers, build a modular monolith instead.

I've helped teams adopt microservices, and I've helped teams dig themselves out of microservices. The second group is bigger.

In almost every failure case, the decision to split came before the reasons did. The app might need to scale someday. The monolith feels messier every sprint. A conference talk made independent deployments look easy. None of those are reasons to take on a distributed system.

Meanwhile, the actual trade is brutal and specific: microservices exchange local complexity for distributed complexity. A method call becomes a network hop. A transaction becomes a saga. A stack trace becomes a distributed trace across three services and a queue.

Sometimes that trade is worth it. I've made it myself, and I'd make it again in the right situation. The five questions below are how I find out. Answer them honestly and the decision usually makes itself.

1. Do Parts of the System Have Genuinely Different Scaling Needs?

I don't mean needs you might have someday. I mean needs you can measure today: one part of the system handles 100x the traffic of the rest, or needs a GPU, or eats memory in a way that forces you to size the whole deployment for its peak.

That's a real reason. Extracting a hot path so it can scale (and fail) independently is one of the best arguments for a service boundary.

But check the honest version first: most .NET monoliths scale out fine behind a load balancer. If your whole app comfortably runs on three instances, you don't have a scaling problem worth a service boundary.

2. Are Teams Actually Blocking Each Other?

Microservices are an organizational tool as much as a technical one. The strongest version of this signal looks like: multiple teams, one codebase, and a release process where team A's half-finished feature delays team B's hotfix. Deploy trains, release freezes, merge queues that take a day.

If that's your life, independent deployability has real value.

If you're a team of six, it isn't. One team doesn't step on itself hard enough to justify operating a distributed system. I'd go as far as saying: below roughly two full teams, the organizational argument for microservices is zero.

3. Can You Draw the Data Boundary?

This is the question that kills most splits, and it's the one people skip.

Each service must own its data outright. Owning it means no other service reads its tables directly, not even for one convenient join. If two candidate services constantly need each other's data to answer basic queries, they aren't two services. They're one service you're about to cut in half.

I learned this one the hard way, and wrote about it in the modular monolith boundary I couldn't take back: a boundary that looks clean on the org chart can be hopelessly entangled at the data level. The entanglement doesn't go away when you add a network between the halves. It gets worse, because now every "join" is an API call, and keeping the data boundaries intact becomes a distributed problem.

4. Does Anything Require Independent Failure or Release?

Some parts of a system carry requirements the rest doesn't:

• A payment flow that must stay up even when the reporting module is down
• A component with a compliance boundary (PCI, HIPAA) where you want the audited surface as small as possible
• An integration that ships weekly while the core ships quarterly

These are legitimate isolation requirements, and a service boundary is a clean way to express them. Notice how specific they are. A general wish for isolation is not on the list.

5. Can You Afford the Platform Tax?

Before the first microservice delivers any value, you need: a container platform, CI/CD per service, centralized logging, distributed tracing, a message broker, and the reliability patterns that make inter-service communication safe (outbox, idempotent consumers, retries with backoff).

That's the entry fee, paid in engineer-months, before benefit number one.

A team that can't spare that capacity doesn't get a cheaper version of microservices. It gets a distributed monolith with none of the benefits and all of the costs.

Scoring It

The rule I use:

• Four or five yes answers: split, and start with one service, not twelve. Extract the piece with the clearest boundary and run it in production for a quarter before extracting the next.
• Two or three: you want modules, not services. A modular monolith gives you the boundaries, the team ownership, and the option to split later, without the platform tax. The boundaries you enforce now are exactly what makes the eventual migration mechanical instead of heroic.
• Zero or one: keep the monolith and invest the energy you just saved into making it excellent.

The teams that regret microservices almost never got the technology wrong. They got this checklist wrong, eighteen months earlier, in the meeting where the split was decided before the reasons existed. Run the five questions before your version of that meeting.

Thanks for reading.

And stay awesome!