Splitting your monolith now has a price tag. The split system costs more than 20% extra to build, and it buys technical debt that grows about 90% slower [2].

A 25-engineer team in our field notes went the other way. It ran 48 services on three Kubernetes clusters (the container system that runs them), and a new backend hire needed three weeks to get going [5]. It merged the code into two modular monoliths, and shipping fell from four days to 25 minutes [5].

The big picture:

The split debate usually runs on taste. But it is a purchase, and now both sides have numbers.

The authors tracked a 50-developer company for over four years. Two teams pulled five business processes out of a 280,000-line codebase [2]. They measured the debt with a code tool across that history, not an estimate.

After the split, technical debt grew about 90% slower [2].

The same study shows the toll. Overall development cost rose by more than 20%, because a split system takes more time to change, test and run [2].

The part I keep circling: teams argue the upside and forget the extra cost. Then it lands as a surprise bill a year later.

Service count adds a second hidden tax. One change that crosses many services ships more than once. Segment logged this in 2018: editing one shared library meant shipping more than 140 services [1].

After Segment merged them back into one service, a single engineer could ship in minutes. Shared-library fixes went from 32 before the merge to 46 in the year after, a count the company read as proof the code had become easier to change [1].

By the numbers

  • 90% — Slower debt growth: technical debt in a 280,000-line system grew about 90% slower once five services came out [2].
  • More than 20% — Development cost premium: the architect and project manager there put the added cost of the split system above 20% [2].
  • 140 to 1 — Service merge: Segment folded more than 140 services into one, and shared-code fixes got much faster to ship [1].
  • $407,940 — Three engineers a year: three times the 2025 median pay for a software developer ($135,980), about what the three full-time engineers Segment kept on its system cost in salary [1][4].

What I’d watch:

Four simple numbers decide whether a split pays. I’ve been watching how teams check them before any code moves.

  • Debt cost against the extra: a split only pays when the yearly cost of holding tech debt beats the 20%-plus build cost [2]. Most teams under 50 engineers sit on the wrong side of that math.
  • Change fan-out: the count of services one shared change touches. Segment hit 140 for one library edit [1]. A two-digit figure points to a packaging problem, not a scaling problem.
  • Service ceiling: one engineer in a survey capped a service at what a team of five to eight can own [3]. By that rule, 25 engineers carry three to five scopes, not 48 [5].
  • The core motive: load was the reason 40 of 53 surveyed engineers gave for pulling a service out [3]. A split made for neat code pays the extra cost and gains no real load separation.
  • The migration order: most of them (27 of 53) moved one service at a time [3]. I’d want to know whether each pulled service still has a clear path back.

The catch

The 90% figure comes from one company, measured once [2]. It is a growth rate, not a saving.

That paper notes an early spike in tech debt from building the new services [2]. The slower growth came after that spike.

Segment’s numbers are its own account of its own work, with no control group [1].

My read: the honest rule is narrower than keeping one big codebase. A split pays when real load problems exist and the team can own each piece. What the evidence rejects is the default split, done for neatness, by a team too small to carry it.

At a glance

  • The Big Shift: Splitting a monolith into services now has a price. The split system costs over 20% more to build, and it buys tech debt that grows about 90% slower [2].
  • Why It Matters: Teams pay that extra cost every year in slower change, and it grows with the service count. Segment needed over 140 code drops for one shared change before it merged them back [1].
  • What I’d Watch: how teams price the split before they move code.
  • Debt cost: the yearly cost of leaving the debt in place, the number the extra cost has to beat [2].
  • Change fan-out: how many services one shared change touches.
  • Service ceiling: how many services a team can own at five to eight engineers each [3].
  • Migration order: one service at a time, with a way back, as most of them did [3].
  • The Catch: the debt measure is one company studied once, the merge account is first-party, and the team ceiling is one engineer’s rule, not a proven threshold [1][2][3].

Related reading

Sources

[1] Twilio Segment, “Goodbye Microservices: From 100s of problem children to 1 superstar”, Alexandra Noonan, 10 July 2018 — https://segment.com/blog/goodbye-microservices/ [2] Valentina Lenarduzzi, Francesco Lomio, Nyyti Saarimäki and Davide Taibi, “Does Migrating a Monolithic System to Microservices Decrease the Technical Debt?”, arXiv:1902.06282v3, 4 July 2020 — https://arxiv.org/html/1902.06282v3 [3] Vinicius L. Nogueira, Fernando S. Felizardo, Aline M. M. M. Amaral and Wesley K. G. Assunção, “Insights on Microservice Architecture Through the Eyes of Industry Practitioners”, arXiv:2408.10434v1, 19 August 2024 — https://arxiv.org/html/2408.10434v1 [4] O*NET OnLine, “Summary Report for Software Developers (15-1252.00)”, 2025 wage data — https://onetonline.org/link/summary/15-1252.00 [5] Editorial-factory field notes, enterprise_tech_leadership Anecdote 2 (internal) — context/growth_os/customer-truth.md