What the Machines See

Chapter 6: Microservices Without Autonomy

When the monolith was split, the coupling did not disappear; it migrated into shared schemas, shared databases, and undocumented inter-service dependencies. The core error was decomposing services by technical layer rather than by business process.

A European insurer operates over five hundred microservices. Each team owns its own set of services, with the “autonomy” to decide how they are built and what they are called, deployments are independent, and the architecture diagrams are beautiful and convincing. Leadership describes the estate as “full microservices in the cloud.”

A regulatory change arrives: all policies above € 25,000 annual premium must observe a mandatory 48-hour cooling-off period before activation. During this window, payment may be collected, the policy may be cancelled without penalty, claims are not valid, and risk exposure must not be recognised on the balance sheet.

The cooling-off-period change alters the policy lifecycle itself, not just a feature within it.

In a system decomposed around business processes, this change would be contained within the policy activation domain. In this estate, “activation” spans five services: quote-to-bind, payments, policy ledger, claims eligibility, and broker commission calculation. Each publishes events consumed by dozens of downstream services. The policy ledger alone has fifty-seven consumers.

Introducing a new intermediate state means that “active” no longer means what it meant yesterday. Every service that relied on the assumption that a policy was either active or not must now reinterpret that boundary. The change requires schema updates across five services and two hundred downstream consumers, migration logic for in-flight policies, regression testing across exposure and solvency reporting, and coordinated deployment across nine teams.

While the actual code implementation requires only three days, the surrounding dependency negotiation consumes four months.

The engineer who identified the scope in week one has attended thirty-one coordination meetings. The engineer's exhaustion is the human cost of a pattern adopted for the wrong reasons.

Few patterns have been embraced as enthusiastically, or misunderstood as thoroughly, as microservices. In most software-dependent corporates they were adopted not to create autonomy but to enable independent deployment inside an organisational structure that could not otherwise move.

...

See also: Full contents · Preview chapters · Illusions in the Boardroom