When Do You Split From the Monolith? The Microservices Decision Without the Hype

In 2023, the question "when do we move to microservices?" seemed obvious, as if the monolith were an engineering disgrace to be shed. But something striking has happened since: major companies began to retreat. Amazon's Prime Video team consolidated a microservices-based monitoring system into a monolithic design, cutting infrastructure costs by more than 90%. Segment split its system into more than fifty services early, then reverted to consolidating its critical paths into a monolith in search of simplicity. And Auth0 partially reverted to a monolith after the operational burden outpaced the benefits. These are not failure stories, but maturity lessons: the architectural decision is not a trend to follow, but a trade-off to calculate.

Why Is This Decision Harder Than It Looks?

The fundamental mistake is that many treat "monolith vs. microservices" as a technical choice, when at its core it is an organizational and business decision affecting your budget, your team's speed, and your product's direction for years. Microservices do not primarily solve a technical problem; they distribute organizational complexity so engineering velocity can scale across many teams. If you do not have this organizational problem, you are paying an "operational tax" for nothing.

The Golden Middle: The Modular Monolith

Before we discuss "when to split," we must break the false binary. The choice is not "a chaotic monolith" versus "clean microservices." The most mature default option in 2026 is the "modular monolith": a single deployment unit, but with strict boundaries between modules inside it, with explicit interfaces, and no cross-module database access. Each module (orders, payments, users) knows what it owns and what it does not. This pattern gives you 80% of the clarity of microservices without their operational complexity, and most importantly preserves the option to "extract" later when the need is real.

And here is the point many miss: the real value is not in "how you deploy" but in "how you split your logic." Good logical separation matters more than physical separation. And whoever splits physically without sound logical separation ends up with the worst of both worlds: a "distributed monolith" with maximum complexity and minimum benefit.

The Decision Criteria: When Do You Actually Split?

Here are the real signals that justify splitting, all organizational or related to strict requirements, not mere "technical preference":

Team size. Microservices begin to pay off when your engineering team exceeds about 20 to 30 engineers. Below that number, they add extra coordination without paying for itself. Teams smaller than ten engineers should stay in a well-organized modular monolith.

Differing deployment cadence. If parts of your system need radically different deploy rhythms (the checkout page deploys daily, billing quarterly), that is a genuine justification for separation. But if they all deploy at the same rhythm, you do not need the architectural separation.

Failure isolation. When one part going down genuinely should not take the rest with it (payments, search, recommendations), microservices excel. If your domain has no strict isolation requirement, you pay the tax for nothing.

Differing scaling needs. If a part has a fundamentally different scaling need (a video processing pipeline needing GPUs should not share the infrastructure of a simple REST API), independent scaling delivers real value in cost and reliability.

The Traps That Ruin the Decision

Three recurring mistakes derail any approach. First: "because Netflix does it." If that is your primary rationale, stop; Netflix's scale almost certainly does not match yours. Second: physical splitting without logical boundaries. When you deploy services that share a database, have circular dependencies, or require coordinated releases, you have created a "distributed monolith" — the disaster of maximum complexity with no benefit. Third, and most dangerous: thinking microservices solve technical debt. If your problem is technical debt, microservices will amplify it, not solve it; because you distribute the chaos over the network instead of containing it in one place.

A New Factor in 2026: AI Tools

A consideration that did not exist three years ago has recently emerged, and it has two faces. On one hand, AI coding assistants (like Copilot and Cursor) work more effectively within a single, well-scoped service with a clear interface contract than navigating a huge monolith with implicit dependencies — a relatively new argument for splitting. On the other hand, "internal developer platforms" (like Backstage and Port) have made managing microservices accessible to smaller teams, as a two-person platform team can manage a twenty-service architecture. These two factors lower the cost of splitting, but they do not repeal the rule that it must be justified by a real need.

The Practical Path: Start Small, and Split Gradually

The 2026 consensus is clear: start with a modular monolith built so it can be split later. Splitting from it is a known, well-tooled migration when revenue and team size justify it. The reverse — folding over-engineered microservices back into a monolith when you discover the mistake — is much harder. And when you do split, do not rewrite everything at once; use the "Strangler Fig" pattern: build new capabilities as standalone services, and extract existing monolith functionality incrementally over 12 to 18 months, without a risky "big bang."

The practical rule that sums up all of the above: do not ask "monolith or microservices?" but "what specific organizational or technical problem am I trying to solve?" If you cannot name a real problem — a team past thirty, or a part that genuinely needs isolation or independent scaling — you most likely do not need microservices yet. The most successful systems are not the most architecturally sophisticated, but those that added complexity only when it was warranted. Start simple, keep your boundaries clean, and split when the facts force you, not the trend.