Five ways monolith decompositions go wrong (and the boring fixes)

About a third of our microservices work isn't building distributed systems — it's rescuing decompositions that stalled somewhere painful: fifteen services, a monolith still doing the important work, and a team that now operates both. The failure patterns repeat so consistently that we keep a list. Here it is, with the corrections.

Mistake one: boundaries drawn from the org chart

Services named after teams — 'the checkout team's service' — inherit the org chart's political boundaries instead of the domain's natural ones. Two years later, every meaningful feature spans four services and requires a coordination meeting. The fix is domain analysis before decomposition: event-storming workshops that map where business capabilities actually begin and end, and where data genuinely needs to change together. Boundaries that follow the domain survive reorgs. Boundaries that follow the org chart don't survive the next one.

Mistake two: the shared database that stays shared

Extracting a service's code while leaving its tables tangled in the monolith's database produces the worst of both worlds — a distributed monolith where a schema change still breaks five 'independent' services. Data ownership is the hard part of decomposition, which is exactly why teams defer it. Each service must own its tables outright, with other services reading through APIs or subscribed events. Yes, this means dual-writes and migration choreography. That work is the migration; the code extraction is the easy part wearing the hard part's badge.

Mistake three: skipping the platform

The monolith gave you deployment, logging, and debugging for free — one app, one log, one dashboard. Fifteen services with no shared platform means fifteen bespoke deployment scripts and incident calls where the first forty minutes are spent finding the right logs. Platform investment — templates, tracing, unified deploys — feels like overhead until the fourth service and feels like survival after the tenth. We now refuse decomposition engagements that don't fund the platform, because we know how the story ends without it.

Mistake four: big-bang cutover dreams

The plan that says 'we'll build the new system alongside and switch over in Q4' has a name in our office: the rewrite trap. The new system chases a moving target while the business keeps changing the old one, and Q4 becomes Q2 becomes never. Strangler migration is slower on paper and faster in reality — one capability at a time, old and new running in parallel, reconciliation proving equivalence before each cutover. Every step ships value and retires risk. No step bets the company.

Mistake five: decomposing for the wrong reasons

Sometimes the honest architecture review concludes the monolith isn't your problem. If deployment pain is really missing CI/CD, and scaling pain is really a missing cache, microservices will relocate those problems and add network partitions on top. The uncomfortable question worth asking first: would a well-modularized monolith with a modern pipeline solve this? Half the time the answer is yes — and it costs a tenth as much. The other half, you decompose with clear eyes and a real reason, which is the only way it works.