Opinions on Microservices Nobody Asked For

Microservices didn't fix your org chart. They just gave the org chart a network boundary.

opinionarchitectureorg-design2026.07.05

The possum, in its questionable decision state — DECISIONSEEMED REASONABLE

REFERENCE CARD

Before you split the service

shared boundary

— same deployment cadence
— shared data ownership
— low operational isolation

service boundary

— independent scaling
— clear ownership
— operational isolation justifies the cost

BOUNDARY MAP

What a service split actually introduces

request

Client

API gateway

ownership

Orders service

Users service

state

Orders data

Users data

The useful boundary is not the box around the code. It is the ownership and failure boundary that comes with it.

THE NEW COST

typescript

A boundary is also a timeout

const response = await usersService.getUser(userId, {
  timeoutMs: 250,
});

if (!response.ok) {
  return fallbackProfile();
}

The network hop is not free. Now the caller needs a timeout, a fallback, and an opinion about stale data.

If two teams can't agree on a shared library, splitting the service in half doesn't resolve the disagreement — it just gives it a network hop and a new set of timeouts to argue about.

Microservices are a legitimate answer to a scaling problem. They are not a substitute for a hard conversation.