Systemsarchitecturemicroservices

The quiet return of the monolith

Nobody announced it. Teams simply started merging services back together and hoping their old conference talks would age gracefully.

A dense circuit board photographed close up, its traces forming a grid
A dense circuit board photographed close up, its traces forming a gridUnsplash

There was never a moment when the industry agreed that microservices had gone too far. There was no keynote, no manifesto, no widely-shared post that everyone now cites. There was just a slow, faintly embarrassed accumulation of pull requests titled “merge billing-service into core”.

I have spoken to engineers at eleven companies over the past four months who are, quietly, undoing a decomposition they performed between 2018 and 2022. Not one of them describes it as a reversal. They describe it as consolidation, or right-sizing, or — my favourite — reducing the surface area of the on-call rotation.

The bill arrives late

The case for splitting a system was always independent deployability, and that case was real. The cost was distributed-systems complexity, and that cost was also real — but it arrived on a delay. A team that split a monolith into fourteen services in 2019 felt the benefit in the first quarter and the bill in the third year, when the one person who understood the retry semantics between services four and nine left for another job.

What makes the bill hard to argue about is that it never appears as a single line item. It shows up as a slightly slower incident response, a slightly longer onboarding, a slightly higher chance that a one-line change requires touching three repositories. Each increment is defensible. The sum is not.

Cascading columns of pale green characters on a dark screen
The observability stack a fourteen-service architecture requires is, itself, a system somebody has to run.

We had better dashboards than we had reasons to look at them.

Staff engineer at a logistics company in Pune

The shape people are landing on

The end state is rarely a return to one process. It is usually three or four services drawn along the lines where the organisation actually splits — the team that owns payments, the team that owns search — rather than along the lines where the domain model looked tidy on a whiteboard.

// 2019 — fourteen services, drawn from the domain model
//   users · profiles · preferences · notifications · templates
//   billing · invoices · tax · dunning · ledger
//   search · indexing · suggest · analytics

// 2026 — four services, drawn from the org chart
//   core       users, profiles, preferences, notifications
//   billing    billing, invoices, tax, dunning, ledger
//   discovery  search, indexing, suggest
//   insights   analytics
The boundary that survives is the one a team can staff.

This is Conway’s law being obeyed on purpose instead of by accident, which is the only version of it that has ever worked. The interesting question is not whether monoliths are back. It is why an industry that has known about Conway’s law since 1967 keeps rediscovering it at the price of a three-year migration.

Comments

Be the first to write in

No letters on this piece yet. The Ledger is a template, so comments are a placeholder — wire this block up to your own backend.