👋 Hey {{first_name|there}},
Why this matters / where it hurts
So you migrated to microservices. It felt like real progress at the time: smaller repos, smaller deploys, and teams could finally move independently.
And then reality showed up uninvited.
Deployments started getting slower, not faster. That "small change" you wanted to ship? Turns out it needs three different services, two teams in a Zoom room, and a rollout plan that reads like a military operation. Incidents stopped looking like bugs and started looking like coordination failures. Oh, and latency? It's been creeping up because every request now takes a grand tour of your entire architecture.
For a while, I blamed the tooling. The CI pipeline is slow. Kubernetes is too complex. Our observability setup is a mess. And yeah, sometimes that's actually the problem, but not nearly often enough to explain what I kept seeing.
The real culprit is usually much simpler: you split your system into services, but the system still behaves like one giant unit. Only now all that coupling happens over the network instead of in-process. That's the distributed monolith. And honestly? It's often worse than the original monolith because you kept all the coupling and added retries, timeouts, partial failures, and version drift on top.
We're going to diagnose the coupling with a straightforward cohesion analysis, then merge the chattiest parts back together before you go splitting things up again, this time with a better rule.
🧭 Mindset shift
From: "Microservices are about nouns. Customer Service, Product Service, Order Service."
To: "Microservices are about cohesion. What changes together should run together."
Here's what happens when you split by nouns: you end up slicing a single behavior across multiple services. Checkout becomes Order + Payment + Inventory + Pricing + Promotions. On paper, each one looks clean and focused. In reality, that behavior is now a distributed transaction with network calls at every turn.
Cohesion is a much better lens. Put together the things that change together, deploy together, and fail together. Split where the change rates and operational concerns actually differ.
Two rules that'll keep you honest:
If a single user action requires 4-10 synchronous service calls, you didn't gain modularity. You just relocated it.
If two services have to ship in lockstep to deliver one feature safely, they're not really separate services yet.