Microservices vs Monolith for SaaS Backends

Choosing between microservices and a monolith for a SaaS backend is mostly a decision about people, money, and operational readiness. A modular monolith is the sensible default. Microservices earn their keep when a specific, present constraint makes separation worth the extra work.

Why this debate keeps producing the wrong answer

The standard debate asks founders how to structure their code before asking what their organization can support. That gets the decision backwards from the start. A small team looking for product-market fit has different needs from several teams that want to release on their own. Yet both can end up discussing the same service mesh, as though the only difference were the catering budget.

The conference-talk narrative helped create this confusion. Teams orders of magnitude smaller took Google, Amazon, and Netflix as their models and came to see microservices as a step forward and monoliths as legacy. DHH calls this “cargo culting,” borrowing patterns from much larger organizations even when their needs point in the opposite direction. Resume-driven development adds another nudge, because Kubernetes and service meshes can look better on a CV than a deliberately uneventful backend.

Does the team have the budget and operational maturity to run independent services, and what problem it has now would those services solve? Without a clear answer, the organization is paying for more complexity on the strength of a forecast. The bill, unfortunately, does not wait for the forecast to come true.

What microservices actually cost, before you ever see a benefit

Microservices introduce infrastructure and coordination costs as soon as services become independent. The infrastructure gap can be a multiple of an equivalent monolith’s baseline. Each service adds deployment and monitoring work. In a setup built around Kubernetes, each needs its own CI/CD pipeline, deployment, and alert configuration. Fifty services means fifty of everything, which is less an architecture diagram than a collection of dependants.

Feature work also crosses more boundaries than before. A change inside one application can become a matter of getting APIs to agree, with contract testing and versioning to back that up. Onboarding expands for the same reason, because understanding the code is no longer enough to understand how the system fits together. None of this makes microservices inherently slow. It means their potential for independent delivery comes with coordination work that a small team may not be able to offset.

Data introduces a harder kind of coordination. Work within a monolith’s shared database can use native ACID transactions, while transactions that span service-owned databases need something such as the Saga pattern to make them work. Network calls add another charge. A local function call takes nanoseconds, while a service call takes milliseconds, and twenty downstream calls can add hundreds of milliseconds of latency. These costs can be justified, but they arrive before the organizational benefits do.

How far a well-structured monolith can actually scale

Shopify’s engineering team gives a clear reason for keeping its monolithic core. “We are very deliberate about when to split functionality out into separate services, and we only do it for good reasons. That's because splitting a single monolithic application into a distributed system of services increases the overall complexity considerably.” Shopify demonstrates why substantial scale does not, by itself, settle the decision in favour of decomposition.

Other production examples reinforce that distinction without needing a roll call of every Rails application ever shipped. GitHub, Intercom, Kickstarter, Bloomberg, and Betterment have retained monolithic backends after considering alternatives. Their choices challenge the idea that a monolith is merely temporary scaffolding. Amazon and Netflix also started as monoliths before adopting microservices.

The important distinction is between a monolith and a tangled monolith. A modular monolith organizes code into clearly bounded internal modules while keeping a single deployable unit. Those boundaries make it clear who owns what, much as services do, while keeping internal calls from becoming network requests. Structure does not require distribution. A tangled application is still tangled when its confusion travels over HTTP.

The four conditions where microservices genuinely pay off

When multiple teams need to release separately, a shared deployment can become the coordination bottleneck. Services can then give teams ownership that aligns responsibility with release control. This is why the same split can help a larger organization while burdening a smaller one.

The second condition is genuinely asymmetric demand. If image processing, AI/ML inference, or a high-throughput event stream needs to scale independently by an order of magnitude, extracting that component can be worthwhile. The operative word is “component,” not “application.” The rest of the backend may have no comparable need. Making every domain run on its own because one workload needs different treatment is a very costly way to show solidarity.

The third condition is regulatory or compliance isolation. Different data residency or regulatory regimes can require separation, including a payments component subject to PCI-DSS or a health data store subject to HIPAA. Whether the data has to be kept separate depends on which rules apply. The fourth condition is a radically different technology need, such as Python for ML inference or Go for high-throughput processing, when the monolith’s primary stack cannot serve it.

These conditions share a testable feature in common. They describe a constraint the team is already experiencing, whether in releases, workload demand, compliance, or runtime requirements. They are not forecasts of eventual importance. If none applies today, the organization has no identified benefit to set against the cost of separation.

A practical framework for deciding where you actually stand

For a team making this choice, the framework starts with present conditions. A smaller engineering team should favour a modular monolith because there may not be enough independent ownership to make services pay off. Before product-market fit, the same choice protects fast iteration and flexibility. Without mature CI/CD or container infrastructure, many independent deployments add work that the organization is not yet ready to handle.

If multiple teams need independent deployments, selective microservices become a reasonable answer. The extraction should target only the domain causing the coordination bottleneck. If one component needs order-of-magnitude independent scaling, that component is the candidate instead. For event-driven or short-lived work such as file processing, webhooks, and scheduled jobs, serverless functions can sit beside the monolith without committing the backend to microservices.

The strangler pattern wraps the monolith behind an API gateway, extracts one service when a specific condition is met, and validates it in production before another extraction follows. It avoids a big-bang rewrite. This tests whether the new boundary earns its operational cost while the existing application continues to serve the business.

Early SaaS, with its first thousand users, can use a modular monolith, shared database, and one deployment pipeline. As usage grows, internal boundaries can harden and background workers can be extracted as needed. At high growth, asymmetric workloads such as AI inference and notification pipelines may justify selective separation. Even at large enterprise scale, the decision remains domain-specific and can sensibly result in a hybrid.

How AI workloads change the architectural calculus without changing the core principle

AI gives SaaS founders in 2026 a legitimate reason to separate a particular class of work. Inference can need independent scaling, a different runtime, and latency and memory profiles unlike the core application’s. Long-running compute jobs introduce another distinct workload.

The recommended pattern is a modular monolith with AI inference workers and long-running compute jobs isolated as separate processes. Core business logic, user records, and subscription state stay in the unified database, preserving ACID guarantees for operations that need them. The workers return results asynchronously to the application.

The same design also supports a coherent view of the business. Keeping authentication, payments, customer data, and AI usage metrics together makes it easier to connect feature use with cost, conversion, and churn. Agent-driven workflows likewise fit a single, normalized API layer better than a fragmented mesh that requires discovery, authentication, and coordination across many endpoints.

The backend fragmentation tax founders pay when they split too early

Premature separation changes both how engineers deploy the application and what the business can see. When authentication, billing, and analytics each have their own service and database, the full picture of a customer is spread across them. One system knows who the customer is, another knows what they pay, and another knows what they use. The information exists, but it is scattered. So answering a founder’s everyday question about customers can turn into a project to bring the data together.

Cross-service analysis then needs custom ETL pipelines or a data warehouse to bring those records together. Those additions create synchronization work of their own. Every new service adds another integration point, webhook, or schema that may need to stay in sync with the others. Separation has spread the work of coordination from application delivery into the machinery used to understand the business.

When user records, transactions, and session events live in one system, the connection between product use and revenue is available without first reconstructing it across service boundaries. This removes a separate integration build from the path to that analysis, especially useful when the same small team is responsible for both shipping features and understanding their effect.

For founders, the lesson is to treat architecture as a data strategy decision too. A modular monolith with a well-designed shared database can help product-led growth by keeping the link between what customers do and how that affects revenue. That benefit belongs in the extraction calculation. A service boundary may still be worthwhile, but engineering independence is not the only thing being bought or sold.

Choosing with evidence, not aspiration

For a new SaaS or AI product in 2026, the practical default is a modular monolith. That choice should change when evidence changes. Team release conflicts, asymmetric traffic, regulatory requirements, and incompatible runtime needs reveal whether a particular domain would benefit from separation.

Before an extraction, the team should ask which of the four conditions is true today and which specific domain is causing the problem. An unclear answer is a reason to wait. A clear answer makes the next decision narrower, because the comparison becomes the cost of keeping that domain inside versus the cost of operating it separately. The strangler pattern then offers a way to act without betting the application on a rewrite.

Microservices are not a destination that every successful SaaS company must reach. A company that never encounters the conditions that justify them has not fallen behind. It has avoided an unnecessary expense. In the next architecture discussion, the useful proposal is not “become microservices,” but “separate this domain because this present constraint costs more than the split.”