Microservices vs Monolith: Decision Framework

I have been writing about system design concepts that tripped me up until I sat down and worked through them. This one is different. It is not a coding problem. It is a software development architecture choice that every engineering team argues about at some point: modular monolith vs microservices.

The Argument That Won't Die

Last year, our team spent three weeks debating whether to break our monolith into microservices. Three weeks. We drew diagrams. We filled Notion docs. People quoted Martin Fowler at each other across Slack. After all of it, I realized we were asking the wrong question.

Should we use microservices does not help anyone. It is like asking should we use a database. The answer is always it depends, and that gets you nowhere. A better question: Given our team size, how often we deploy, our scaling needs, and our infrastructure readiness, which architecture reduces friction the most?

That reframing changed our entire conversation. So I built a decision framework out of it. Not the textbook kind. The practical kind, based on thresholds that actually matter.

Why This Debate Is Louder in 2026

The industry is going through a correction. A 2025 CNCF survey found that 42% of organizations that adopted microservices now merge services back into larger units. Nearly half of the companies that went all-in on microservices are walking it back.

The reasons are not technical. They are economic. Distributed systems cost more to build, more to run, and more to debug. When interest rates sat near zero and teams grew 30% year over year, nobody noticed the overhead. Now they notice.

The modular monolith pattern has also grown up fast. Frameworks like Spring Modulith, .NET Aspire, and newer Go module patterns give you clean domain boundaries inside a single deployable. You get 80% of the organizational wins of microservices (clear ownership, defined interfaces, the ability to independently deploy modules) at maybe 20% of the running cost.

The question is not monolith or microservices anymore. It is how much distribution does my system actually need?

The Four Variables That Actually Matter

After working through this decision with our team and reading how other organizations approach it, I have found that four variables predict the right architecture with surprising accuracy.

Team Size

This is the single strongest predictor. If fewer than 30 engineers work on the product, a modular monolith is almost certainly the right call. The coordination tax of microservices (service contracts, API versioning, tracing, independent CI/CD pipelines) will slow you down more than it helps.

The tipping point sits around 50 engineers. Merge conflicts in a monorepo start hitting daily. Build times stretch past 15 minutes. Deployment meetings eat into actual development time.

Between 50 and 100 engineers, the modular monolith starts creaking. Above 100, the case for splitting services becomes very strong.

Team Size -> Architecture Fit
---------------------------------------------
< 30 engineers    -> Modular monolith (strong default)
30-50 engineers   -> Modular monolith with 1-3 extracted services
50-100 engineers  -> Hybrid (monolith core + extracted hot paths)
100+ engineers    -> Microservices (with caveats)

Deployment Frequency Mismatch

This one is less obvious but just as important. If every part of your system deploys on roughly the same schedule (say, once or twice a week), a monolith works fine. The pain shows up when deploy frequencies pull apart.

Picture an e-commerce platform. The checkout service needs to deploy three times a day for A/B testing and fraud rule updates. But billing deploys once a quarter because every change needs compliance review. Locking those two in the same deployable means the checkout team waits on billing approvals, or the billing team gets dragged into releases they do not own.

When you see a 10x or greater mismatch in deploy frequency between parts, that is a strong signal to extract. Not the whole system. Just those specific parts.

Scaling Characteristics

If your entire application scales uniformly (every endpoint sees similar load patterns), a monolith with horizontal scaling works well. You spin up more instances behind a load balancer and you are done.

Microservices earn their complexity when scaling needs are genuinely heterogeneous. Maybe your image processing pipeline needs GPU instances while your API layer runs fine on general compute. Maybe your real-time notification service handles 50x the requests of your reporting dashboard. In those cases, running everything in the same process wastes resources because you are scaling the entire application to satisfy the hungriest component.

But be honest with yourself here. We might need to scale differently someday is not the same as we have measured scaling bottlenecks that cost us money today. The first is speculation. The second is engineering.

Infrastructure Readiness

This is the one most teams underestimate. Microservices do not just need application code. They need infrastructure code. A lot of it. Container orchestration (Kubernetes or similar), service discovery, centralized logging, tracing, circuit breakers, API gateways, and on-call runbooks for every service boundary.

If your team lacks dedicated DevOps or platform engineering staff, microservices will bury you. I have watched teams spend more time debugging infrastructure than building product features. They adopted microservices before they had the foundation to support them.

A practical checklist: if you do not have centralized logging (ELK or similar), tracing (Jaeger, Zipkin), container orchestration (Kubernetes), and automated deploy pipelines, you are not ready for microservices. Full stop.

Infrastructure Readiness Checklist
---------------------------------------------
[ ] Centralized logging (ELK, Datadog, etc.)
[ ] Tracing (Jaeger, Zipkin, etc.)
[ ] Container orchestration (Kubernetes, ECS)
[ ] Automated CI/CD per service
[ ] Service mesh or API gateway
[ ] On-call rotation with runbooks
[ ] Failure testing

Score: 5+ checked -> ready for microservices
Score: 3-4 -> invest in platform first
Score: < 3 -> stay with monolith

The Decision Tree

Putting the four variables together, here is the decision tree I use:

Start with team size. If under 30, go modular monolith. Do not overthink it.

If 30-100, check deployment frequency mismatch. If components deploy at wildly different cadences, extract those specific components. Keep everything else in the monolith.

If 100+, check infrastructure readiness. If you have the foundation in place (the checklist above), move toward microservices. If you do not, invest in the platform first. Premature microservices without infrastructure readiness is the number one cause of architecture regret I have seen.

At any team size, check scaling characteristics. If specific components have genuinely different resource needs that are costing you money, extract those components regardless of team size. But only those components.

The Majestic Monolith Pattern

The architecture winning most often in 2026 is not purely one or the other. Some call it the majestic monolith with extracted hot paths. One well-structured modular monolith as the core, with two or three separated services for the parts that have a real reason to live alone.

At our company, the main application is a modular monolith. But the image processing pipeline runs as its own service because it needs GPU instances. The webhook delivery system is separate because it needs to scale on its own when a large client onboards.

Everything else lives in the monolith. Domain modules with clear interfaces keep it organized.

This pattern works because it matches reality. Most of your system does not need its own deploy pipeline. Most of your system does not have unique scaling needs. But some of it does, and those parts should live on their own.

A New Variable: AI Coding Assistants

Three years ago, this factor did not exist. AI coding tools like GitHub Copilot, Cursor, and Claude Code work better within a single, well-scoped service with clear contracts. Smaller, bounded services get more effective help from AI tooling.

This creates a tension. AI tools make developers more productive within a bounded context, which pushes toward splitting services. But AI tools also make it easier to manage a larger codebase, which pushes toward keeping things together.

My take: this is a secondary factor. Do not split your architecture to make AI tools happy. But if you are already on the fence, the AI productivity boost within bounded services is worth noting.

What I Got Wrong the First Time

Going back to that three-week debate on my team. We eventually decided to keep the monolith and invest in better module boundaries instead. It was the right call. We were 22 engineers, we deployed twice a week uniformly across the system, and our DevOps setup was two Terraform scripts and a prayer.

If we had gone to microservices, we would have spent six months building infrastructure instead of features. I know this because the team that sits next to us did exactly that. They had a similar team size, similar product complexity, and they went the microservices route. Six months later, they had four services, a Kubernetes cluster they barely understood, and a deployment pipeline that broke every other week.

The lesson: your architecture should match your organization actual state, not where you hope to be in two years. You can always extract services later when the need is real. You cannot easily merge them back once they are separated.

Quick Reference: When Each Architecture Wins

Choose modular monolith when:

• Team is under 50 engineers
• Deployment cadence is uniform across components
• Scaling needs are homogeneous
• No dedicated platform engineering team
• You are still discovering domain boundaries
• Speed to market matters more than theoretical scalability

Choose microservices when:

• 100+ engineers work on the product
• Teams need to independently deploy at genuinely different frequencies (10x+ mismatch)
• You have measured scaling bottlenecks that cost real money
• A dedicated platform/DevOps team exists
• Domain boundaries are well-understood and stable
• Independent team autonomy is an organizational priority

Choose the hybrid (modular monolith + extracted services) when:

• 30-100 engineers
• Most parts deploy uniformly but 1-3 have wildly different needs
• You have the infrastructure for extracted services but not for the full system
• Specific parts have unique scaling or technology needs

I have been working through system design problems on Levelop and this architecture decision kept coming up in the design tracks.