👋 Hey {{first_name|there}},
Most teams don't have a microservices problem. They have a boundary problem. Here's a triage card that tells you which one you're actually solving.
Why this matters / where it hurts
I once joined an architecture review for a team that had split a monolith into fourteen services over the previous year. Fourteen. The original app was an e-commerce order management platform with maybe six developers working on it. They had a service for catalog image resizing. A service for email notifications. A service whose only job was to format prices for different currencies and locales.
The deploy pipeline took forty minutes. Every feature touched three or four repos. A schema change in the checkout service required coordinated releases across five downstream consumers. The team spent more time on integration testing and deployment choreography than on actual product work. Their sprint velocity had dropped by roughly 40% since the migration, and nobody could explain why, because on paper, they had done everything the architecture blogs recommended.
The problem was not microservices. The problem was that nobody had asked, before splitting, whether the pain they were feeling actually required independent deployability, or just better internal structure. In Lesson #34 on the distributed monolith, we covered how services that share databases, deploy in lockstep, and break when their neighbors change are really just a monolith with network calls. This week we tackle the decision that comes before the split: how to figure out whether splitting is the right move at all.
🧭 The shift
From: "We need microservices to scale."
To: "We need clear module boundaries. Deployment topology is a separate decision."
Here's what I think people get wrong about this. The benefits everyone attributes to microservices, clear ownership, independent evolution, and safer changes mostly come from modularity. Not from putting a network boundary between two things. A well-structured monolith with enforced module boundaries will get you surprisingly far. I'd say 80% of the way there, though honestly, that number varies depending on how disciplined your team is about respecting the boundaries once they exist.
The remaining 20% is real, though. Independent scaling, independent deployment, polyglot flexibility. Those are genuine advantages you cannot get from a monolith. But they come packaged with distributed tracing, network failure modes, contract management, and infrastructure cost that someone has to pay for. So the actual question is not "monolith or microservices." It's whether your specific situation generates enough pressure in that 20% zone to justify the operational tax. Most teams I've worked with overestimate how much pressure they actually have.
Default to a modular monolith until you have concrete evidence that a specific module needs independent deployment or independent scaling. Not theoretical evidence. Concrete.
Treat service extraction as a response to measured pain. Not as a proactive architectural investment you'll be glad you made later. You probably won't.
If two services must deploy together to avoid breaking changes, they are one service. Call them that.
📘 New Career Guide
I just finished a major update to the From Developer to Architect career guide. It now includes a self-assessment rubric, a week-by-week 90-day growth plan, architecture artifact templates, and interview prep frameworks. If you're actively working toward a Staff, Tech Lead, or Architect role, this is the structured roadmap.
Free download here: https://www.techarchitectinsights.com/from-developer-to-architect-free-career-guide