الدرس 2 من 2
The Symptoms That Actually Mean It Is Running Out
Four signals worth acting on, four that are usually misread, and the cheaper interventions to try before any of them justifies distribution.
Monoliths do reach limits, and pretending otherwise is as unhelpful as splitting prematurely. The skill is telling a real limit from a symptom with a cheaper cure, because the cheap cures are available in weeks and the expensive one takes years.
| Complaint | Usual actual cause | Cheaper intervention |
|---|---|---|
| "Deployments are risky" | A long pipeline and coupled modules, not the single unit | Faster pipeline, trunk-based development, feature flags, canary release |
| "Teams block each other" | No enforced ownership of code areas | Module boundaries with owners and a build-time check |
| "It cannot scale" | Database contention or in-memory state | Read replicas, connection pooling, statelessness, targeted caching |
| "Onboarding takes months" | Missing internal structure and documentation | Enforced modules, an architecture overview, a working local setup |
| "Builds take 40 minutes" | A monolithic build, which is not the same as a monolithic runtime | Incremental builds, test partitioning, build caching |
| "One bug takes everything down" | No isolation between workloads inside the process | Separate the risky workload into its own process or worker, not the whole system |
Establishing whether the limit is real
- 1
Measure release blocking, do not estimate it
Count the times in the last quarter that one team's release was delayed by another's work, and how long each delay lasted. Teams consistently report this as constant and measure it as four times a quarter — or as forty. Both answers change the decision.
- 2
Profile the resource shape per component
CPU, memory, connections and request volume, attributed to components. Independent scaling is only worth buying when one component's profile differs by an order of magnitude from the rest.
- 3
Locate the actual failure domain
Review the last ten incidents. If eight of them originated in one component and took the system down, that component is the candidate — not an arbitrary split of the whole application.
- 4
Try the cheap interventions and measure again
Faster pipeline, enforced modules, feature flags, statelessness. These take weeks, help regardless of the eventual decision, and frequently remove the symptom entirely.
- 5
If a limit remains, extract the one component
Extract the specific component the evidence points at, not the whole system. One extraction gives you real data about your organisation's ability to operate services before you commit to twelve.
In practice
A monolith that had genuinely run out
A media analytics company had 90 engineers in eleven teams on one deployable. Releases happened twice a week in a coordinated window. In one quarter, 31 team-releases were delayed by another team's failing tests, and one report-generation component consumed 70% of total CPU in unpredictable bursts.
Constraints
- Eleven teams, 90 engineers
- Pipeline already at 9 minutes; feature flags already in use
- Module boundaries enforced for two years
- Report generation bursts to 40x baseline CPU
Decision
Extract report generation first, then split the remainder along the four bounded contexts identified in a domain workshop, one context per quarter, keeping the modular monolith as the default home for anything without a specific reason to leave.
Why
Both hard signals were present and measured: an order-of-magnitude resource difference in one component, and 31 counted blocking incidents in a quarter after the cheap interventions had already been applied. Two years of enforced module boundaries meant the extraction candidates had clean surfaces and separate schemas, which turned each split into weeks rather than months.
What it cost
They now run five deployables, a message broker, distributed tracing and a platform team of six that did not previously exist — roughly 7% of engineering capacity spent on operating the system rather than building it. Blocking incidents fell to under five per quarter and report bursts stopped affecting the main application. They wrote the calculation down explicitly, because in two years someone will ask why the platform team exists.
A team says the monolith is slowing them down
As a developer
Takes it at face value — the people doing the work are the best source on friction — and starts designing the split that will remove it.
As an architect
Takes it equally seriously and treats "slowing us down" as a symptom needing a diagnosis, because the same sentence covers a slow pipeline, unclear ownership, a flaky test suite and genuine release contention, and those have four different cures ranging from a week to two years. The response is to ask for last quarter's numbers, not to doubt the complaint. Believing the pain and questioning the proposed remedy is the whole job here.
A company with three teams and a well-modularised monolith wants to split into three services so each team can own one. Is team ownership a sufficient reason?RevealHide
Not on its own, because the ownership they want is already available. Enforced module boundaries with named owners give each team a code area nobody else may change, which is most of what "owning a service" means day to day. Services add release independence on top — and that is worth buying only if teams are actually blocked by each other's releases, which is measurable. Ask for the number: if it is four blocking incidents a quarter, three services will cost far more than they save; if it is thirty, the case is real. There is also a second question worth asking, which is whether three teams can each run a service on call, because ownership includes being paged at three in the morning and that is often the part nobody signed up for.
Key takeaways
- Most complaints about monoliths have cheaper cures than distribution: pipeline speed, enforced modules, statelessness, feature flags.
- Four signals genuinely justify a split, and all four are measurable rather than felt.
- Measure release blocking and per-component resource profiles before deciding, not after.
- Extract the one component the evidence points at first; it also tests whether your organisation can operate services at all.
- Conway's law means team structure and deployment structure will converge — decide deliberately or the organisation decides for you.