TCP #139: The strangler fig that strangled nothing after 18 months
How to sequence which seam gets cut first, second, and third, so the pattern converges instead of stalling at two services forever.
Eighteen months ago, this team adopted the strangler fig pattern to decompose their monolith.
Today they have exactly two services extracted. Both projects are frozen.
The pattern was fine: route traffic through a facade, peel off one capability at a time into its own service, shrink the monolith until there’s nothing left to strangle.
It’s the industry‑standard answer to “how do we decompose this without a rewrite” for a reason: it avoids the big‑bang rewrite that kills most modernization efforts.
But a pattern is not a plan.
Service #1 was picked because an architect had a strong opinion
Service #2 was picked because a team volunteered
Service #3 never got picked because nobody has a reason for one seam over another
The strangler fig didn’t fail. Sequencing did.
Why a Stalled Decomposition Is Worse Than No Decomposition
A monolith that never started decomposing is a known, stable cost.
A monolith that stalled halfway is a compounding one.
The facade/routing layer is now permanent infrastructure to maintain and debug
Two teams now own two services plus the monolith = more surface area, not less
“Independent deployability” exists for a tiny slice of the system, but the overhead is everywhere
The benefits were supposed to justify the cost across the whole estate, not two endpoints.
Worse, a stalled strangler erodes political capital:
Every quarter without visible progress makes the next planning cycle ask, “Why are we still funding this?”
A modernization program that can’t show acceleration starts to look like one that should be cut
The biggest risk with strangler fig was never “can we write the code.”
It was “can we keep organizational patience long enough to see compounding benefit.”
Why Sequencing Gets Skipped
Even teams that implement the pattern correctly stall because the literature explains how to cut a seam and says almost nothing about which seam you cut next.
So the default becomes:
Whoever yells loudest claims the next capability
Or the team that’s free “volunteers” for some random slice of the monolith
You get one extraction that proves the pattern is technically possible, but teaches you nothing about how to prioritize the other nine seams.
Momentum from the first service doesn’t transfer, because no one defined what made that seam a good choice in a way you can reuse.
Complicating it: most monoliths don’t have neat, obvious seams.
Some capabilities share tables and code with three others
Some are already almost independent, and you just haven’t admitted it
Without a scoring framework, teams default to:
Extracting the easiest seam (often least valuable to isolate), or
Extracting the most important seam (often the most coupled and riskiest)
Both patterns look busy, and both fail to converge.
The Sequencing Framework: Score Every Seam on 3 Axes
Before extracting anything, list candidate seams and score each one on three axes.
The scores decide the order. Not titles. Not volunteers.
1. Coupling: how entangled is this capability?
Reads/writes mostly its own tables, with a narrow, clear interface → high score (good early candidate)
Reaches into 5 shared tables that 3 other capabilities also mutate → low score (leave for later)
Early extractions should teach the team the pattern, not force data‑ownership wars.
2. Change frequency: how often does this code change vs the rest of the monolith?
Changes weekly, competing for deploy slots and reviews → extracting it pays off immediately in deploy velocity
Hasn’t changed in 2 years → clean seam or not, business impact of extraction is low
This is where the business case for extraction actually lives.
3. Blast radius: what else breaks if this service misbehaves after extraction?
Narrow, well‑understood set of downstream dependents → safer to extract early
Half the monolith calls into it transitively → extract later, when the team has more practice operating the new shape
First services should be low‑coupling, high‑change, low‑blast‑radius:
Come out cleanly
Prove value quickly
Fail safely if something goes wrong
High‑coupling, high‑blast‑radius seams come later, when extraction and incident handling in the new world are muscle memory.
What Sequenced Decomposition Looks Like a Year In
A sequenced strangler doesn’t produce “two services and a stall.” It produces a visible curve.
After a year, you can point to:
X capabilities now independently deployable
Y% of changes flowing through services instead of the monolith
Incidents that used to take down everything now contained to a single service
That curve is what protects the program when budget season comes.
A modernization effort that can show three good extractions in the first two quarters, each easier than the last because the team is getting better at the pattern, doesn’t have to beg to keep going.
It has evidence.
The payoff isn’t just an architecture that eventually decomposes.
It’s a program that never has to re‑justify itself every quarter, because the sequencing is the proof that it’s working.
That’s it for today!
Did you enjoy this newsletter issue?
Share with your friends, colleagues, and your favorite social media platform.
Until next week — Amrut
Get in touch
You can find me on LinkedIn or X.
If you would like to request a topic to read, please feel free to contact me directly via LinkedIn or X.