When is the answer not microservices?

We are asked the microservices question in perhaps half of our engagements, and our answer pattern has been stable for years: usually no, occasionally emphatically yes, and the discriminating variable is almost never the one in the deck. This briefing writes the pattern down.

what problem does the pattern actually solve?

Precision first, because the word has blurred. A microservice architecture spends operational complexity to buy independent deployability: separate release cadences, separate scaling, separate failure domains, separate teams. That is the entire trade. Every other claimed benefit (performance, reliability, "scalability" unqualified) is downstream of one of those four or is marketing. The costs are equally concrete: a network where function calls were, distributed transactions where local ones were, an observability bill, and an operational floor below which the estate cannot be simplified again without a program.

Stated that way, the question answers itself in most rooms. The trade pays when the bottleneck is organizational: when teams genuinely block each other's releases, when one component's scaling profile is holding the fleet's hardware hostage, when a failure domain must be isolated for regulatory or blast-radius reasons. The trade does not pay when the bottleneck is a slow query, an unclear domain model, or a codebase that is simply old. Those problems travel intact into the distributed version, where they cost more to visit.

what would have to be true?

Our standing question, applied. For microservices to be the answer, three things would have to be true, and teams check the first at most.

The seams would have to be known. A service boundary is a one-way door, expensive to redraw once traffic and contracts accumulate. Boundaries drawn before the domain is understood harden the misunderstanding; how big a service should be is a question with a known method, and the method requires domain knowledge that young systems do not yet have. A monolith is, among other things, a cheap place to be wrong about boundaries.

The organization would have to exist. Independent deployability buys nothing without independent teams to exercise it: separate on-call, separate roadmaps, genuine ownership. Five engineers operating forty services have not adopted an architecture; they have adopted a hobby with a pager. We put the ratio bluntly in reviews: if services outnumber engineers, the architecture is running the team.

The operational floor would have to be funded. Deployment pipelines, tracing, service-to-service auth, backpressure between components (see what backpressure tells you): this floor costs real headcount before the first business feature ships across it. The pattern's successful adopters paid it knowingly. Its unhappy ones discovered it, invoice by invoice.

when is it emphatically yes?

Fairness requires the other column, and it is real. We have recommended extraction without hedging when: a single component with a hostile scaling profile (a renderer, a model server) was holding a fleet's capacity plan hostage; a compliance boundary needed a failure and audit domain of its own; an acquisition made two codebases one company and one codebase was never going to happen; and, twice, when an organization of several hundred engineers had genuinely saturated a monolith's release process and had already built the operational floor for other reasons. Note the shape of every item: the driver is organizational or physical, never aesthetic.

what do we recommend instead, usually?

The unfashionable middle. A modular monolith with enforced internal boundaries buys most of the domain clarity at a fraction of the operational price, and it preserves the option: modules with clean seams extract cheaply later, in the order the organization actually needs, which is where a monolith ends when it ends well. Extraction as a response to a named, measured constraint has a success rate we would put, from our own engagement history, well above extraction as a target architecture. The first is engineering. The second is fashion with a pager.

The question in the title, then, has a working answer: the answer is not microservices whenever the problem can be named without the word "team" or a unit of physics in the sentence. Name the problem first. The architecture is the second sentence, and in most rooms we visit, it is a shorter one than the deck expected.