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.

Microservices Without Autonomy The change is straightforward. A logistics company needs to add a new delivery status, “held at customs,” to the tracking flow visible to customers. The status already exists in the customs clearance system. It needs to propagate to the shipment tracking service, which feeds the customer-facing portal.

In a system with real boundaries and owned contracts, this is two days of work. One team adds the status to its published event contract. The consuming team reads the new event and renders it in the portal. Both teams can do this independently, on their own release schedules, with a versioned contract governing the interaction. In practice, however, the actual sequence unfolds very differently.

The shipment tracking service does not own its own data model. It reads from a shared database maintained by a “data platform” team. The data platform team has a change request process that requires approval from three service owners, because any schema modification affects all consumers. The customs clearance system publishes events, but the tracking service does not consume them directly; it waits for the data platform to ingest and transform them.

Team A (customs) submits a change request to add the new status to the shared schema. The data platform team evaluates the request, determines that the new enum value conflicts with a field used by the returns service, and opens a discussion with Team B (returns). Team B is mid-sprint on a different priority and cannot engage for two weeks. Meanwhile, the customer portal team (Team C) begins building a UI for the new status, discovers that the tracking API does not yet expose it, and files a dependency ticket against the data platform.

Three sprints pass. Four teams are involved. Seven meetings are held. The change is eventually delivered. It is celebrated, without irony, as a cross-team collaboration success.

The two-day change took six weeks. Nobody considers this unusual. The engineer on Team A who raised the original request has rescheduled her team's sprint three times to accommodate it. She does not escalate. There is nothing to escalate to.

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. The architecture diagrams are beautiful and convincing. Leadership describes it 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.

...

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