👋 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
🧰 Tool of the week: Monolith vs. Microservices Triage Card
Monolith vs. Microservices Triage Card: Score your system before you split it.
For each dimension, score your current state honestly. Not where you want to be. Where you are.
Team size and autonomy - Count the engineers who commit to this codebase weekly. Under 15 and working in the same business domain? A monolith is likely fine. Over 15 with distinct sub-teams who keep stepping on each other in code review? That friction is real, and it points toward extraction.
Deployment cadence mismatch - This one is overused as a justification, so be honest. Do different parts of the system genuinely need to ship at different speeds? If your billing logic changes monthly but your notification templates change hourly, that is a real signal. If everything ships on the same sprint cycle anyway, you do not have a deployment boundary problem. You have a habit.
Data coupling density - Map the tables or collections that would be shared across the proposed service boundary. If more than 30% of writes on one side require reads from the other, you are drawing the line in the wrong place. Redraw before you split. I cannot stress this enough. This is where most extractions quietly fail.
Scaling axis divergence - Does one component have a meaningfully different resource profile from the rest? A CPU-heavy image pipeline sitting next to a memory-heavy caching layer is a legitimate argument. Two CRUD endpoints with similar traffic patterns are not, regardless of how different they feel conceptually.
Operational budget reality - This is the dimension teams skip. Estimate the real cost of running the extracted service on its own: CI/CD pipeline, monitoring, on-call rotation, contract testing, and network config. If your team cannot absorb that without slowing feature delivery, the extraction is not free. Delay it.
Failure isolation requirement - Has a failure in module A actually taken down module B in the last six months? Not hypothetically. Actually. If yes, and you have already tried in-process isolation options like bulkheading within the monolith (Lesson #39 covers this), then extraction is probably justified. If no, you might be solving a problem you don't have yet.
Organizational boundary alignment - Check whether the proposed service boundary matches a real team boundary. If the same three people owned both sides of the split, congratulations, you have just added coordination overhead with zero ownership benefit. Services should follow team topology. Not the other way around.
Scoring: If fewer than three dimensions show genuine pressure, stay monolithic and invest in internal module boundaries. Three or four? Extract surgically, one service at a time, starting with the highest-pressure dimension. Five or more? You likely have a real case, but validate data coupling density first. That single dimension has quietly killed more extractions than all the others combined.
🔍 In practice: The order platform that almost split too far
Scenario: A 10-person team running an e-commerce order management platform. The CTO wants to "move to microservices" before Black Friday. The tech lead runs the triage card before committing.
Scope: The entire order monolith - product catalog, cart and checkout, payment processing, warehouse fulfillment, notification dispatch, and catalog image processing.
Context: 10 engineers, single deploy pipeline, ~5 deploys per week, shared PostgreSQL database, one on-call rotation.
Walking through the card:
Team size: 10 engineers, well below the threshold. Occasional merge conflicts in the checkout flow, but nothing that blocks anyone for more than an hour. Score: no pressure.
Deployment cadence: Most of the system moves on the same sprint rhythm. Marketing pushes catalog and image updates more frequently, but those changes are mostly data, not code. Score: mild pressure on one axis.
Data coupling: Cart, checkout, and payment share 8 tables with cross-boundary writes on every order. Splitting them would require distributed transactions or an event-driven sync layer for something that currently runs in a single database transaction. Score: high coupling, do not split here.
Scaling divergence: Catalog image processing (resizing, format conversion, thumbnail generation) spikes hard during bulk product uploads and competes with checkout API traffic for CPU. During a seasonal catalog refresh last quarter, checkout p95 latency doubled. Score: real pressure, one specific module.
Operational budget: No dedicated platform engineer. The team barely has capacity to maintain the current CI/CD pipeline. A second deploy pipeline, monitoring dashboard, and contract test suite would pull someone off feature work for at least a month. Score: low budget for broad extraction.
Failure isolation: An image processing job last quarter consumed all available worker threads and caused checkout timeouts for nearly two hours during a flash sale. Score: real blast radius problem, but traced to one module.
Org boundary alignment: No formal sub-teams. Everyone rotates across the codebase. Score: no pressure.
Result: Two dimensions showed genuine pressure, both pointing at the same module: catalog image processing. Instead of splitting into six services along technical layers, the team extracted image processing as a single async service with its own queue and scaling group. Everything else stayed in the monolith with stricter internal module boundaries enforced through ArchUnit-style dependency rules.
The tradeoff we accepted: Cart, checkout, and payment logic still live in the same deployable. A bad migration in the payment module can still degrade checkout. We decided that was acceptable given the team size and the cost of splitting tightly coupled transactional flows. The plan is to revisit when the team crosses 18 engineers or when a second module shows independent scaling needs.
Measurable outcome: Deploy time dropped from 34 minutes to 11 (the image service deploys independently on its own cadence). Checkout p95 latency stayed flat through the next catalog refresh. The team shipped the extraction in two and a half weeks instead of the four months the full microservices plan was estimated to take.
✅ Do this / ❌ Avoid this
Do this:
Run the triage card before every proposed service extraction, even if "everyone knows" it should be a separate service.
Start with the highest-pressure dimension and extract only the module that dimension points to.
Enforce module boundaries inside the monolith with static analysis tools before considering network boundaries.
Avoid this:
Splitting because "we'll need to scale eventually." Eventually is not a deployment topology.
Drawing service boundaries around technical layers (API service, database service, queue service) instead of business capabilities.
Extracting a service without first proving you can deploy it independently, including schema changes, without coordinating with the monolith.
🎯 🎯 This week's move
Pick one service boundary your team has discussed splitting (or has already split) and run it through the seven-dimension triage card.
For each dimension, write a single honest sentence about your current state. Not your roadmap. Your reality.
If the card says "stay monolithic," identify two internal module boundaries you could enforce with static analysis rules this quarter.
If the card says "extract," verify that data coupling density is below 30% cross-boundary writes before scheduling the work.
By the end of this week, aim to: Have a filled-out triage card for one real service boundary, with a written recommendation (stay, extract, or redraw the boundary) that you could present in a 10-minute team discussion.
👋 Wrapping up
Modularity is a design property. Where you deploy is an infrastructure decision. I think a lot of teams get into trouble because they let the second one drive the first, and then they are stuck operating with complexity they never actually needed. The best architecture is not the most distributed one. It is the one your team can ship with, reason about, and wake up to at night without dreading it.
Know someone making the jump from developer to architect? Forward this email or share your personal link. When they subscribe, you unlock rewards.
🔗 Your referral link: {{rp_refer_url}}
📊 You've referred {{rp_num_referrals}} so far.
Next unlock: {{rp_next_milestone_name}} referrals → {{rp_num_referrals_until_next_milestone}}
View your referral dashboard
P.S. I’m still working on two new rewards. If there’s something you are interested in, let me know 😉
⭐ Good place to start
I just organized all 40 lessons into four learning paths. If you've missed any or want to send a colleague a structured starting point, here's the page.
Thanks for reading.
See you next week,
Bogdan Colța
Tech Architect Insights