Microservices vs Monolithic: Trade-offs and When to Choose
Every growing engineering team eventually has the same argument. Someone wants to split the checkout service out of the main application. Someone else points out that the last three outages all traced back to a service boundary nobody had tested. Both people are right, which is exactly why "monolithic vs microservices" doesn't have a universal answer.
This isn't a case where one architecture is modern and the other is legacy. Plenty of large, successful systems run as monoliths. Plenty of others have split into dozens of services and are healthier for it. Martin Fowler, whose writing on this topic is widely cited in the field, has described a pattern he's observed repeatedly. Most successful microservice systems started as a monolith that outgrew itself, while systems built as microservices from day one run into trouble more often than not. That's one experienced architect's observation, not a population-wide study, but it's a useful check on any advice that treats microservices as the default starting point.
The honest version of this decision isn't about which architecture is better. It's about which one matches your team's size, your operational maturity, and how much coordination overhead you can absorb right now. That's the version this guide covers, as part of our broader look at API architecture patterns and modern approaches.
Monolithic vs. Microservices: The Core Difference
A monolithic architecture ships an application as a single deployable unit. Whichever code makes up the system gets built, tested, and released together, so a change anywhere in it means redeploying the whole thing. A microservices architecture breaks that same functionality into a set of independently deployable services, each with its own release cycle and its own area of responsibility, that communicate over the network, typically through APIs.
What actually distinguishes the two isn't how many repositories the code lives in, or whether the UI ships separately from the backend. Plenty of monoliths keep a separate front-end codebase, and plenty of microservices estates live in a single monorepo. What distinguishes them is the deployment boundary: one unit that moves together, versus many units that can move independently.
The table below covers the dimensions that actually change your day-to-day work, not just the textbook definition.
| Dimension | Monolithic | Microservices |
|---|---|---|
| Development | One shared build and test suite across the whole application (repository layout can vary) | Independent build and release pipeline per service (repository layout can vary, including monorepos) |
| Deployment | One deployable unit. A change anywhere requires redeploying the whole application | Services deploy independently. A change to one service doesn't require redeploying the rest |
| Scaling | Scale the entire application together, even if only one part needs more capacity | Scale individual services based on their own load |
| Debugging | A single process and (usually) a single log stream make root-causing easier | A request may cross several services, so tracing a failure means correlating logs and traces across boundaries |
| Cost | Lower operational overhead, with fewer moving parts to run and monitor | Higher baseline infrastructure and tooling cost (service discovery, tracing, orchestration) |
Neither column is "correct." The columns describe two different sets of trade-offs, and which set costs you less depends entirely on where your team is right now.
Monolithic Architecture: Advantages and Disadvantages
A monolith's biggest advantage is that it removes an entire category of problems before they exist. There's one codebase to check out, one test suite to run, one thing to deploy. A new engineer can trace a request from the API layer down to the database query without opening a service map. When something breaks, the stack trace usually points straight at the cause instead of trailing off at a network call.
That simplicity has a ceiling. As the codebase grows, unrelated features start sharing internal state in ways nobody planned, and a change in one module can break another that a different team owns. Because everything ships together, a slow test suite or a risky change in one corner of the app can block releases for the entire team. Small changes end up touching disproportionately large areas of the code, since the components are interdependent by construction rather than by explicit contract.
The practical failure mode isn't that monoliths "don't scale." Plenty do, for a long time. It's that the coordination cost of shipping through one shared codebase rises as more people try to touch it at once, well before the application's request volume becomes the bottleneck.
None of this means a monolith has to be a tangled mess. A modular monolith keeps strong internal boundaries (one module per business capability, clear interfaces between modules, no reaching into another module's internals) while still deploying and running as a single unit. It gets you most of the organizational clarity that service boundaries provide without paying for the network yet, and it's usually a more honest first step than jumping straight to microservices before you actually know where the real boundaries in your system are.
Microservices Architecture: Advantages and Disadvantages
Microservices solve the coordination problem directly by giving each team a service boundary they fully own. A team can change their service's internals, pick their own release cadence, and scale their piece of the system without asking permission from every other team. That autonomy is the entire point of the architecture, and it's genuinely valuable once an organization has grown past the size where a shared codebase is the fastest path to shipping.
The cost shows up in everything that used to be free inside a single process. A request that once was a function call is now a network call, with its own latency, its own failure modes, and its own security boundary. Data that used to live behind one set of ACID transactions across the whole system typically moves toward eventual consistency between services. For the workflows that still need to look atomic to the business, an order that touches payment, inventory, and shipping, for example, teams reach for patterns like Sagas. A saga is a sequence of local transactions, each with a compensating action that undoes it if a later step fails.
That's a recovery mechanism, not a stronger consistency guarantee than a single ACID transaction. A saga gets the system back to a consistent state eventually, but it doesn't give you the isolation or all-or-nothing atomicity that a local transaction would. Debugging a cross-service request means correlating logs, traces, and timestamps across systems that don't share a process, which is a fundamentally different skill from reading a single stack trace.
There's also a well-documented failure mode worth naming directly: a "distributed monolith," where services are deployed separately but still can't actually change independently. That usually shows up as a shared database, a release of one service that forces a coordinated release of others, or a chain of synchronous calls that makes every service's behavior fragile to changes in the others. A synchronous call between two services isn't automatically a problem on its own. Plenty of healthy microservices estates use them. What makes it a distributed monolith is when that coupling quietly removes the independence the architecture was supposed to buy. You've paid for the network and the operational overhead without actually getting teams that can ship on their own schedule. That pattern is what happens when a team splits a codebase along the wrong seams. It's the worst outcome available, and it's more common than most write-ups admit.
How to Actually Choose: Team Size and Operational Maturity
Most comparisons stop at a pros and cons list and leave you to guess. A more useful lens treats this as an organizational question first and a technical one second: what does your team's structure and operational maturity actually support right now?
Team Size and Conway's Law
Software teams tend to build systems that mirror how the teams themselves communicate. Organizational structure doesn't dictate architecture the way a law of physics dictates motion, but it shapes it more than most teams expect, and ignoring that influence is a common way architecture decisions go sideways.
This pattern is usually called Conway's Law, and it explains a pattern you've probably seen. A single team maintaining a system with a dozen internal modules tends to keep those modules coupled, because the people writing them talk constantly and coordinate informally. Once you have several teams that each need to ship on their own schedule, that same coupling tends to turn into a queue, because now a change requires a conversation across team boundaries instead of a hallway conversation within one.
Resist the urge to reach for a headcount number here. A team of twelve that ships one product with tight internal coordination can run a monolith comfortably for years. A team of six that owns three genuinely separate customer-facing products, each with its own release cycle and its own on-call rotation, may already be better served by service boundaries. The tradeoff that actually matters is that deployment independence becomes more valuable as more people need to ship without blocking each other, while the coordination overhead of running many services scales with the number of services you operate, not the number of engineers on staff. Count teams and release cadences, not people.
Operational Maturity
Team structure only tells half the story. The other half is whether your organization already has the operational muscle that microservices assume as a baseline. That means centralized logging that can correlate a request across services, distributed tracing, an on-call rotation that can triage a failure without knowing which of a dozen services caused it, and a CI/CD pipeline built for independent service deployments rather than one big release train.
None of that is exotic, but all of it takes real investment to stand up, and skipping it doesn't make the need go away. It just means the first serious production incident becomes the moment your team discovers the gap. If your monitoring and on-call practices are still built around "check the one app server," that's a more reliable signal that you're not ready for microservices than any count of developers on the roster.
When a Monolith Is the Right Call
Choose a monolith when a single team, or a small number of teams that coordinate easily, owns the whole system and can ship it together without stepping on each other. This is the common case for a new product, a system still finding product-market fit, or an internal tool where request volume and team size are both modest. It's also a legitimate long-term choice for systems that never grow past the size a shared codebase serves well.
A monolith is also the right call when your operational tooling isn't there yet. If you don't have centralized tracing, a mature CI/CD pipeline, and an on-call process that can handle distributed failures, adding a dozen network hops between services adds risk without adding capability. Building those capabilities first, inside a well-organized monolith, is a more defensible path than adopting microservices and building the operational maturity to support them at the same time.
When Microservices Are the Right Call
Choose microservices when multiple teams need to ship independently and the coordination cost of a shared codebase has become the actual bottleneck, not a theoretical one. The signal usually isn't subtle. Releases get delayed by unrelated changes, one team's risky deploy routinely breaks another team's feature, or different parts of the system have such different scaling profiles that scaling the whole application together wastes real money.
Microservices also make sense when specific parts of the system need isolation for reasons beyond convenience. Examples include a payments flow that needs its own security boundary and audit trail, a component that has to scale independently by orders of magnitude compared to the rest of the app, or a regulatory requirement that mandates separating certain data paths.
Atlassian has described its own move away from a single-tenant monolith, hosted in its own data centers, for Jira and Confluence as a response to concrete scaling and growth pressure on those specific products, not a stylistic preference for a newer architecture. That's the pattern worth copying: the decision followed a specific, named operational problem, and the architecture followed the org chart and the roadmap, not the other way around.
Migrating From Monolith to Microservices (When You're Ready)
If the signals above point toward microservices, the safest path starts inside the monolith, not outside it. Identify clear module boundaries before you draw any network boundaries. A module that already has a clean internal interface, minimal shared state with the rest of the codebase, and an obvious owning team is a good first candidate to extract. A module that's tangled through half the codebase is not, no matter how badly you want it out.
Extract one service at a time and keep it behind the same API contract the rest of the application already expects, so callers don't need to know whether they're talking to a function call or a network call. Atlassian's own re-platforming effort followed this staged pattern. The company moved Jira and Confluence to a new hosting model first, then planned service decomposition as a subsequent phase rather than a single cutover. Build the operational tooling (tracing, service-level monitoring, an on-call rotation that understands the new topology) alongside the first one or two extractions, while the blast radius is still small, rather than after you've split ten services and discovered you can't see across any of them.
This section is intentionally brief. A full migration playbook, including specific extraction patterns and data-ownership strategies, is its own piece of work and worth treating separately once you've decided migration is actually warranted.
The API Layer Works for Either Path
Here's a point most architecture comparisons skip entirely. The choice between a monolith and microservices doesn't have to be the same decision as how you expose and govern your APIs. A well-designed API layer sits in front of whatever is running behind it, whether that's a single application or a dozen independently deployed services, and it's what lets external and internal consumers keep using stable, versioned APIs while the architecture underneath continues to evolve. Teams evaluating API gateway options often assume this is a decision they have to make at the same time as the architecture decision. It isn't.
That matters because it removes a false choice teams sometimes make: assuming you have to adopt microservices just to get proper API governance, rate limiting, and access control. You don't. Strong API management can sit in front of a monolith today and keep working, unchanged from the consumer's perspective, as pieces of that monolith get extracted into services over time.
WSO2's API Platform is built around this idea directly. Its API Gateway and a unified control plane handle policy enforcement, authentication, and monitoring the same way regardless of what's running behind them. That control plane isn't limited to WSO2's own gateway either. It can also discover and govern APIs running on other vendors' gateways, such as AWS, Azure, Kong, and Envoy, alongside WSO2's own, so a team that's already running other vendors' gateways alongside a growing set of extracted services isn't forced into an all-or-nothing re-platform just to get consistent governance. As services get decomposed piece by piece, the API layer is one part of the system that shouldn't need to be redesigned every time the backend architecture changes underneath it. Read more about WSO2's API Platform architecture if you want to see how the control plane and gateway layers fit together.
This shows one common way to lay out each architecture, not a required one. "Own DB" represents each service owning its data logically. It doesn't have to mean a dedicated physical database server. Services can share underlying infrastructure while still keeping separate schemas and access paths. The API gateway shown here mediates traffic from external clients, not necessarily every internal service-to-service call, which is why the microservices side is labeled "service-to-service calls over the network" separately from the gateway box.
Conclusion
The monolithic vs microservices decision holds up best when it's made from your team's actual constraints (how many teams need to ship independently, how mature your operational tooling is, and how expensive coordination has genuinely become), not from whichever pattern is loudest in the industry conversation this year. A monolith that fits your team is a better system than a microservices architecture you adopted because it seemed inevitable.
If you're weighing this decision alongside how you'll expose and govern APIs either way, WSO2's API Platform is built to support both starting points, so the API governance decision doesn't have to wait on the architecture decision getting settled first.
Frequently Asked Questions
Is Netflix monolithic or microservices?
Netflix runs on microservices today. The company has described its own migration away from a monolithic, data-center-based Java application, moving to AWS and converting the system into cloud-based microservices starting in 2008 as streaming traffic grew, in its engineering blog.
Is Amazon monolithic or microservices?
Amazon's retail platform started as a monolithic application, internally called Obidos, and moved to a service-oriented, and later microservices-based, architecture as the company scaled. Amazon CTO Werner Vogels has described this transition in a published interview.
Can you give me an example of a monolithic application?
A typical example is a single web application where the user interface, business logic, and database access all live in one codebase and deploy together as one unit, common for early-stage products and internal tools.
What are the three types of microservices?
There's no single official taxonomy, but services are commonly grouped by role: domain or business-capability services (handling a specific function like billing or inventory), infrastructure or platform services (shared concerns like authentication), and integration or gateway services (mediating traffic between consumers and the rest of the system).
