The microservices reckoning of the last few years has produced one durable lesson: splitting a service should be a last resort, not a first instinct. Most of the value claimed for microservices can be achieved with a well-modularised monolith and a disciplined deployment pipeline.
When you do split, run through this checklist first.
The ten questions
- Will the new service be owned by a different team? If not, the split is mostly cost.
- Does it have a meaningful boundary? A boundary is meaningful when the two sides change at different rates or for different reasons.
- Can it be deployed independently? If your CI still gates one on the other, the split is illusory.
- Does it own its data? If both services read and write the same tables, you have not split anything — you have added a network hop.
- Have you defined the contract? Versioned, typed, with a clear deprecation policy. Not "REST" or "GraphQL" — the actual schema.
- Have you defined the SLA? Producers consume SLAs. Without one, every incident becomes a finger-pointing exercise.
- Is the operational story funded? Logging, tracing, metrics, on-call rotation, runbook. Microservices multiply operational work.
- Is the rollback story defined? Schema changes that span services are the most expensive bugs to undo. Plan for it.
- Have you measured the latency budget? Each hop is a few milliseconds in steady state and a long tail in incidents. Budget it.
- Is the team genuinely too big for the monolith? This is the only test that matters. Conway's Law is not subtle.
What a healthy split looks like
The microservices architectures we see succeed are usually three to seven services per fifty engineers, not fifty services per fifty engineers. Each service owns its data, has a dedicated team, and exposes a versioned contract. Teams can deploy without coordinating. Incidents are isolated.
The architectures we see fail share a property: they were designed before the team existed. The org chart was reverse-engineered to fit the architecture, the team is too small to own its share, and every change is a coordination problem.
Start with a modular monolith. Split when the team and the boundary both demand it. Resist the temptation to do it any earlier.