Monolithic vs microservices pros and cons: four inputs that decide

Microservices vs monolith: which should most teams choose?#

Most teams should start with a modular monolith, one deployable split into modules with clear boundaries, and move a part out to a service only when its team, release pace or load demands it. By contrast, microservices split a system into small services that each run, ship and store data on their own. A monolith is one codebase, one deployable and usually one database.

Four inputs decide which style fits a given part of your system.

1. Team size

   How many teams must change this part without waiting on each other.

2. Releases per week

   Whether this part must ship far more often than the rest.

3. Parts that scale differently

   Whether one part takes load in a pattern the rest does not.

4. Operations maturity

   Whether you already run automated deploys, fast provisioning and monitoring.

When none of those four push, the modular monolith wins on cost and on simplicity. Fowler made the same point in his MonolithFirst note of 3 June 2015. In his words, "Almost all the successful microservice stories have started with a monolith that got too big and was broken up." So start there, and treat a split as something a part has to earn.

What is the difference between monolithic and microservices architecture?#

A monolith ships as one deployable with one database, while microservices split the system into separately deployed services that each own their data and talk over the network. That boundary drives every cost that follows. In a monolith, one module calls another as a function call inside the same process. Every module reads and writes the same database. In microservices, that call becomes a network request, and each service keeps its own store.

James Lewis and Martin Fowler called this "Decentralized Data Management" in their March 2014 article on microservices. Microsoft's Azure Architecture Center, updated 11 July 2025, put it in plainer words. Microservices, it says, "are responsible for persisting their own data or external state".

The modular monolith sits between the two. It keeps one deployable and one process. But each module owns its tables and talks to other modules only through a defined interface. So calls stay fast and local, while tests and code review enforce the boundaries instead of the network.

Google Cloud's guide to microservices, read on 4 October 2026, names the gain most teams want. It says "Individual microservices can be scaled independently based on their specific needs." That gain is real. However, it only matters for a part whose load differs from the rest.

So here is how the three compare on the seven things a CTO usually weighs. The cells are a rule of thumb, not measurements.

What are the monolithic architecture pros and cons?#

A monolith is simpler to build, test, debug and run, but as the codebase and team grow, every change waits on one shared release and one shared scaling unit. The pros come first, because they are real. One codebase means one build, one deploy and one place to search. Because a request runs in one process, a stack trace shows the whole path. Also, a database transaction keeps data correct without extra design, and a new starter learns one system.

But the disadvantages of monolithic architecture appear with growth, not on day one. First comes the shared release. When dozens of people change one deployable, every change waits for the slowest test suite and the riskiest merge. Second comes the single scaling unit. When one part needs far more capacity, you scale the whole app to get it.

Those two pressures match what researchers found. Fritzsch, Bogner and Wagner studied 14 systems at 10 companies through 16 interviews and published the results on arXiv in June 2019. They named maintainability and scalability as the primary migration drivers.

Yet size alone does not break a monolith. In February 2019, Shopify wrote in Deconstructing the Monolith that more than a thousand developers had worked on its Ruby on Rails codebase over a decade. It was still one codebase, and the team chose to make it modular rather than split it. So the disadvantages of a monolith are real, but they often have a cheaper fix than a split.

What are the disadvantages of microservices over monolithic architecture?#

Microservices turn function calls into network calls, trade one database for eventual consistency between many, and multiply the pipelines, upgrades and on-call rotations a team must run. Fowler listed these costs in his Microservice Trade-Offs article of 1 July 2015. For distribution, he noted that "remote calls are slow". He warned that everyone has to manage eventual consistency. That means two services can briefly disagree about the same fact until a message catches up. And on operations his line was blunt: "You need a mature operations team" to manage lots of services.

Each of those costs lands on a real person. Because a request that crosses several services can fail at each hop, every caller needs timeouts and retries. A customer order that touches billing and stock no longer sits in one transaction, so you design for the gap. And every service brings its own pipeline, alerts, dependency upgrades and a place in the on-call rota.

Fowler's MicroservicePrerequisites note of 28 August 2014 sets the floor: rapid provisioning, basic monitoring and rapid application deployment. Without those three, he advised against the style.

Teams often adopt Kubernetes along with microservices, and Amazon EKS puts a price on falling behind with its upgrades. Amazon Web Services' Amazon EKS pricing page, read on 4 October 2026, charges $0.10 per cluster per hour while your Kubernetes version is in standard support. That support lasts 14 months after Amazon EKS releases the version. So if you fall behind on upgrades, the same October 2026 AWS price list moves the cluster to extended support at $0.60 per cluster per hour. A monolith on EKS pays the same fee. What grows with the split is the upgrade work, because every service must be checked against each new version.

What does running eight services cost compared with one monolith?#

At AWS list prices read on 4 October 2026, eight services cost $158.39 a month against $87.29 for the same product as one monolith. Every assumption is stated so you can redo the sum. The region is US East (N. Virginia). A month is 30 days of 24 hours, as in the examples on the AWS Elastic Load Balancing price page read that same day.

Both designs run on Amazon Elastic Container Service (ECS) with AWS Fargate, which bills for the vCPU and memory each container uses. The Amazon ECS pricing page, read on 4 October 2026, says there is "no additional charge for Amazon ECS orchestration." The monolith runs as 2 copies, each with 1 virtual CPU (vCPU) and 2 GB of memory. The eight services run as 2 copies each at the smallest size the AWS Fargate page listed on 4 October 2026, 0.25 vCPU and 0.5 GB. Both sit behind one Application Load Balancer.

The monolith's size is itself an assumption, set so both designs carry the same load. The split costs more only because every service needs at least the smallest task, twice over for availability. Sixteen small tasks add up to 4 vCPU and 8 GB, double the monolith's 2 vCPU and 4 GB, so the gap is that per-service floor.

Three things are left out on purpose: the database, the load balancer's usage charges, and tooling such as logs, tracing and build minutes. Usage charges follow traffic and rules, but the database and tooling tend to grow with each service, so these figures are a floor for the split, not a ceiling.

The prices come from the AWS Fargate pricing page and the Elastic Load Balancing pricing page, both read on 4 October 2026. Fargate charges $0.000011244 per vCPU per second and $0.000001235 per GB per second on Linux. An Application Load Balancer costs $0.0225 an hour.

On Kubernetes the gap would be wider. The cluster fee is the same in both designs, but the Amazon EKS Fargate pod guide, read on 4 October 2026, says "Fargate adds 256 MB to each Pod's memory reservation" for Kubernetes components, which lifts each small pod to the next size. Even so, the cloud bill is rarely the number that decides.

Where does the extra cost of eight services come from?#

The load balancer costs the same either way, so the infrastructure gap is all compute, and the bigger gap is the people time each extra service takes. In the worked example, the load balancer hours cost $16.20 a month in both designs. Only compute moves, and it doubles, because sixteen small containers use twice the vCPU and memory of two medium ones.

The bill misses the larger cost, which is time. Say each service takes 6 hours a month: 4 for upgrades and pipeline fixes, and 2 for on-call handovers. Say the monolith, being larger, takes twice that, 12 hours. Both are assumptions for illustration, not measured figures. Eight services then take 48 hours a month against the monolith's 12, which is 36 extra hours.

Those hours have a public price too. The US Bureau of Labor Statistics put the median annual wage for software developers at $135,980 in May 2025, in its Occupational Outlook Handbook read on 4 October 2026. Over a 2,080-hour working year that is $65.375 an hour. That is base wage before employer costs, so the figures below understate the gap. At that rate, a little over one extra hour of upkeep a month, across all eight services, costs as much as the whole $71.09 cloud gap. That break-even needs no assumption about hours. On the illustrative 36 hours, the wages come to $2,353.50 a month, over thirty times the cloud gap.

Segment lived this at scale. In July 2018, Alexandra Noonan of Segment, now part of Twilio, wrote Goodbye Microservices. In it she said, "The overhead from managing all of these services was a huge tax on our team." She also described 3 full-time staff spending most of their time just keeping the system alive.

How does the monthly bill grow with each service you add?#

In the worked example the bill climbs from $51.75 a month at two services to $300.57 at sixteen, while the load balancer stays flat. The one input to change is the number of services. Each service adds 2 small containers, and each container adds $8.89 a month of compute.

The infrastructure line grows in a straight line, so you can price your own count: multiply your services by $17.77 and add $16.20. The people line grows the same way. At 6 hours a service, it reaches 96 hours a month at sixteen services.

Four services cost exactly what the monolith did, because they use the same total vCPU and memory. The gap only opens as the count rises, and it opens in people time faster than in dollars.

What is a modular monolith, and why is it the right default?#

A modular monolith is one deployable split into modules that own their data and talk through defined interfaces, which keeps a monolith's simple operations and gives teams microservices-style boundaries. In practice, a module owns a slice of the business, such as billing or the catalogue, along with its tables. Other modules call it only through its public interface and never reach into its tables. A test or a build check fails any change that breaks the rule. So the boundary holds without a network in the way.

Shopify took this route with more than a thousand developers on one codebase. In its February 2019 write-up, the team said microservices "would bring their own set of challenges". Then it wrote, "We chose to evolve Shopify into a modular monolith." So it kept all the code in one codebase and made sure boundaries "were defined and respected between different components."

Fowler's MonolithFirst note gives the deeper reason. In it he wrote that even experienced architects "have great difficulty getting boundaries right at the beginning". Building a monolith first, he argued, lets you find the right boundaries before a split makes them costly to move.

That is why the modular monolith is the default. It costs what a monolith costs to run. On the worked example's assumptions, its upkeep stays close to the monolith's 12 hours, because it is still one app to run. Every module is already a candidate service. When a part later earns its own service, you lift out a module that already has an interface and its own data. The interface can start as a plain function call and become a web or event contract later. For those choices, see the guide to choosing an API style for each boundary.

Which teams consolidated services back into one?#

Segment described in 2018 how it folded over 140 services into a single service, and in 2023 Prime Video moved one monitoring service's distributed parts into a single process. Segment's case was about operations. Its pipeline had grown one service per destination, and shared libraries meant one change could force a deploy of all of them. After the move, Noonan wrote in 2018, "We no longer had to deploy 140+ services for a change to one of the shared libraries."

Prime Video's case was about cost and scale. In March 2023, Marcin Kolny of Prime Video Tech described an audio and video monitoring service. Its first version was built from distributed parts orchestrated by AWS Step Functions. That design, Kolny wrote in 2023, hit "a hard scaling limit at around 5% of the expected load". So the team moved every part into a single process. As Kolny wrote in the archived 2023 Prime Video Tech post, "Moving our service to a monolith reduced our infrastructure cost by over 90%."

Neither account says microservices are wrong. Both describe what the split cost them before they reversed it. Prime Video's case is also a warning about cutting too fine. Parts that pass large data to each other on every request belong in one process.

When should a part move from a modular monolith to microservices?#

A part should move once it has its own team, needs about ten or more releases a week that the shared release blocks, and you already run automated deploys, fast provisioning and monitoring. That is a rule of thumb, and microservices are then the better tool for that part, not for the whole system. Microsoft's Azure Architecture Center sets the size. A microservice, it says, "should be small enough that a single feature team can build, test, and deploy it." So the trigger is a team that keeps waiting on other teams' releases. Total headcount alone is not the trigger, since Shopify, by its own 2019 account, kept more than a thousand developers on one modular codebase.

Three cases mark the exits. First, a part meets the team and release trigger above. Second, a part has a sharply different load pattern, such as a media pipeline or a search index. Third, a part needs a different runtime or data store for a real reason. In each case, move that part out and keep the rest modular.

The fourth input is the gate. Fowler's prerequisites of August 2014 are rapid provisioning, basic monitoring and rapid application deployment. If you cannot start a server in hours, spot a failing service fast and ship without ceremony, fix that first. If you want help putting that floor in place, see DevOps and continuous delivery services.

The selector's thresholds are a rule of thumb, not a measured line. Its 10-person mark counts the people who change one part, not the whole company. So set it for each part of your system.

In what order should you split a monolith into services?#

Split one part at a time, starting with the one whose team, release pace or load differs most, and route traffic to it while the monolith keeps the rest. Sam Newman's book Monolith to Microservices, published by O'Reilly in 2019, takes that step-by-step approach. Its chapter on splitting the monolith covers the strangler fig application. There, new code grows around the old system and takes over one route at a time. It also covers branch by abstraction. With it, an interface inside the monolith lets you swap the old module for a call to the new service.

Amazon Web Services also lists both patterns in its Prescriptive Guidance on decomposing monoliths, read on 4 October 2026.

The order matters because the cut is the hard part. Fritzsch, Bogner and Wagner reported in June 2019 that finding the right service cut was a major technical challenge. Most companies in their study preferred a rewrite, often for want of a suitable decomposition approach. But a rewrite stalls feature work for a long time, so the incremental route is the safer one.

Prime Video's monitoring service shows what a cut that is too fine costs: its parts always ran together and passed data on every request. Keep parts like that together, and split along the lines where teams, releases or load really differ.

If you are modernising an older monolith and want a second pair of hands on the order, see maintenance and support for existing systems. For the frontend version of the same move, the incremental strangler migration guide walks through it one route at a time.

Where should you go from here?#

Start from a modular monolith, measure the four inputs each quarter, and split a part out only when the numbers say it has earned its own service. The worked example puts a floor under that habit, and the larger cost is people time, which grows with every service.

1. Team size

   Does a team keep waiting on other teams' releases to change this part?

2. Releases per week

   Must this part ship far more often than the rest?

3. Parts that scale differently

   Does this part take load in a pattern the rest does not?

4. Operations maturity

   Can you start a server in hours, spot a failing service fast and ship without ceremony?

For the frontend half of the microservices vs monolith decision, see micro-frontends with Module Federation. If you are starting a new product and want the modular monolith set up from the first commit, see custom software development. Otherwise, the sources linked above from Fowler, Newman, Segment and Prime Video are enough to make the call.