Keep the Monolith Until 150 Engineers: Why Microservices Cost 30–50%

Default to a modular monolith. Extract to microservices only when you have a concrete, organization-level reason: a team that has grown past roughly 150 engineers, workloads with genuinely divergent scaling profiles, or a regulatory boundary like PCI or SOC 2 that demands isolation. Microservices carry a real operational tax, often estimated at 30 to 50 percent of engineering capacity once you cross the network boundary, so the burden of proof sits with the team asking to split things apart, not the one keeping things together.

---

TL;DR:

• Expanding to microservices is costly, adding 30 to 50 percent more engineering capacity needed for operation, especially if services share databases or deploy together.
• A team larger than 150 engineers is usually necessary for microservices to offset coordination overhead, divergence in scaling, and regulatory constraints effectively.
• Smaller teams under 30 should stick to monolithic or modular architectures due to lower complexity and faster delivery, avoiding the operational burden of microservices.
• Migrating incrementally using the strangler fig pattern is recommended, beginning with low-coupling bounded contexts and avoiding premature data ownership transfers.
• Conduct an honest architecture review to assess team capacity, CI/CD maturity, and bounded contexts before committing to microservices or breaking up a monolith.

Table of Contents

• Monolith vs Microservices: Definitions You Need Before You Decide
• Deployment, Data, and Coupling: Where the Two Approaches Actually Diverge
• Trade-Offs That Actually Show Up in Real Projects
• When to Stay Monolith, Go Modular, or Adopt Microservices
• How to Migrate Without Building a Distributed Monolith
• The Distributed-System Tax: What Microservices Actually Cost You
• How Ampersand Approaches This Decision With Clients
• Why “Monolith-First” Still Beats the Industry Hype
• Get an Honest Architecture Review Before You Split Anything
• Sources
• FAQ

Monolith vs Microservices: Definitions You Need Before You Decide

Half the arguments about “microservices vs monolith” collapse once everyone agrees on what the words mean. A classic monolith is a single deployable unit, usually one codebase, one build, one database, where every module runs in the same process and shares the same schema. It’s the fastest way to ship a working product, and it’s how nearly every successful software company started.

A modular monolith keeps that single deployable but enforces internal boundaries: modules talk through defined interfaces, own their own data tables even inside the shared database, and could theoretically be pulled apart later without a rewrite. It’s still one thing to deploy, one thing to monitor, and one transaction model, but the code doesn’t turn into a tangled mess as it grows.

Microservices mean independently deployable services, each owning its own data store, communicating over the network rather than in-process function calls. Microsoft’s Azure architecture guidance frames this as the defining trait: if a service can’t ship without coordinating a release with three other teams, it isn’t really a microservice yet.

Check your own codebase against these markers:

• Can you deploy one module without redeploying the whole application?
• Does each domain own its own tables, or does everything join across the same schema?
• Do modules call each other through language-level function calls, or over HTTP/gRPC/message queues?
• Does your CI/CD pipeline build and test the system as one unit, or many independent ones?

Deployment, Data, and Coupling: Where the Two Approaches Actually Diverge

The differences that matter aren’t philosophical. They show up in four concrete places: how you ship code, how you store data, how components talk to each other, and how your teams are organized around all of it.

Deployment and release coupling. A monolith ships as one unit. Every change, whether it touches the billing module or the login page, rides the same build and the same release train. Microservices decouple that: a payments team can ship ten times a day while the inventory team ships once a week, and neither blocks the other. That independence is the single biggest reason large organizations pursue the split.

Data ownership. Monoliths typically run one logical database, which makes cross-domain queries and transactions trivial. You just join tables. Microservices push toward database-per-service, often with different storage engines for different needs (polyglot persistence), which kills easy joins and forces you to think in eventual consistency, sagas, and API composition instead. Microservices catalogs these patterns because almost every team reinvents them the hard way first.

Coupling and failure modes. In-process function calls fail rarely and fail fast. Network calls between services introduce a new failure category entirely: timeouts, partial failures, retries, and the need for circuit breakers. The network becomes part of your architecture whether you planned for it or not.

Team ownership and Conway’s Law. This is the axis people underweight. Architecture tends to mirror the communication structure of the organization that builds it. A team of 12 engineers splitting a product into nine services isn’t practicing good architecture, it’s fighting its own org chart. Decomposition should follow team boundaries, not precede them.

Trade-Offs That Actually Show Up in Real Projects

The pros and cons of each approach aren’t abstract. They hit your calendar, your budget, and your on-call rotation.

1. Monoliths win on speed to market. One codebase, one deploy pipeline, one place to set a breakpoint. Debugging a request end-to-end means reading one stack trace, not stitching together distributed traces across five services.
2. Monoliths win on initial infrastructure cost. One database, one hosting bill, no service mesh, no per-service monitoring stack. For most startups this alone should end the debate early.
3. Microservices win on independent scaling. If your image-processing workload spikes 50x during peak hours while your user-profile service stays flat, splitting them lets you scale the expensive part without paying to scale everything else.
4. Microservices win on team autonomy and fault isolation. A crashing recommendation engine doesn’t have to take down checkout if they’re separate services with separate failure domains.
5. The biggest risk is the distributed monolith. Services get split on paper, but they still deploy together, share a database, or call each other synchronously in long chains. You inherit all the operational cost of microservices with none of the independence benefit.
6. Sprawl is real. More services means more repositories, more pipelines, more dashboards, and more places for a junior engineer to get lost at 2 a.m. during an incident.

When to Stay Monolith, Go Modular, or Adopt Microservices

Team size is the most reliable predictor of which architecture will actually work for you, more reliable than traffic volume or even technical complexity.

• Under roughly 30 engineers: stay monolithic, ideally modular. You don’t have the headcount to staff a platform team, and coordination overhead between two people is basically zero anyway.
• Roughly 30 to 150 engineers: this is modular-monolith territory for most teams, with selective extraction of one or two services that have a genuinely different scaling profile or a hard regulatory boundary.
• Above roughly 150 engineers: microservices start paying for themselves because the coordination cost of dozens of teams shipping through one release train exceeds the cost of running distributed infrastructure. The HLD Handbook frames this as an organizational pattern as much as a technical one.

Beyond headcount, three workload signals suggest extraction is worth it: divergent scaling needs between components, latency requirements that differ wildly by function, and bursty traffic that would force you to overprovision the entire monolith just to handle one hot path.

Regulatory isolation is the other legitimate trigger. If PCI DSS scope or SOC 2 boundaries require that payment data never touches the same process or network segment as everything else, that’s a real architectural constraint, not a preference.

Before extracting anything, run this readiness checklist:

• Do you have a platform team, even a small one, dedicated to shared infrastructure?
• Is your CI/CD pipeline automated enough to support independent deploys without manual gatekeeping?
• Do you have real observability: distributed tracing, centralized logs, and service-level dashboards?
• Are your bounded contexts genuinely clear, or are you guessing where the seams are?

Pro Tip: If you can’t answer “yes” to at least three of those four readiness questions, extraction will cost you more in the first six months than it saves. Fix the readiness gaps first, or stay modular a while longer.

How to Migrate Without Building a Distributed Monolith

Almost every successful microservices migration started as a monolith and moved piece by piece, never as a clean-slate rewrite. The strangler fig pattern is the standard approach, and it works because it never asks you to bet the company on a big-bang cutover.

1. Put a routing layer in front of the monolith. An API gateway or reverse proxy sits between clients and your system, initially forwarding 100% of traffic to the existing monolith.
2. Pick one bounded context to extract first. Choose something with low coupling to the rest of the system, a clear owning team, and data needs that don’t require constant joins with other domains. Notifications or search are common first candidates; core billing rarely is.
3. Build the new service and dual-run it. Route a slice of traffic to the new service while the monolith still handles the rest, and compare outputs before fully cutting over.
4. Migrate the data ownership last, not first. Keep the monolith’s database as the source of truth until the new service has proven stable, then move ownership and backfill.
5. Repeat, one bounded context at a time, retiring monolith code as each extraction stabilizes.

Watch for the anti-pattern the whole industry keeps rediscovering: services that are “independent” on the architecture diagram but must all deploy together in practice. The HLD Handbook’s rule of thumb is blunt: count how many services need to ship in lockstep for any given release. If it’s most of them, you’ve built a distributed monolith and you’d be better off consolidating. Contract testing between services and feature flags during rollout catch most regressions before they reach production.

The Distributed-System Tax: What Microservices Actually Cost You

Crossing the process boundary isn’t free, and the bill is bigger than most teams budget for. The HLD Handbook’s estimate puts the distributed-system tax at roughly 30 to 50% of engineering capacity once you’re running production microservices, a figure that covers observability tooling, versioning discipline across service boundaries, and the on-call burden of debugging failures that span five services instead of one stack trace.

That tax shows up in specific line items:

• Per-service CI/CD pipelines instead of one shared pipeline.
• Distributed tracing and centralized logging, because “check the logs” now means checking five different log streams.
• A platform or SRE function dedicated to shared infrastructure, service mesh, and deployment tooling.
• Saga and outbox patterns to manage transactions that used to be a single database commit.

Mitigations exist, mainly platform engineering that automates the repetitive parts and observability patterns baked in from day one rather than bolted on after an outage. Tools that handle routine operational work can absorb some of that tax, but they don’t eliminate it. If your team can’t staff that ongoing platform investment, the honest answer is to stay monolithic, or modular, until you can.

How Ampersand Approaches This Decision With Clients

A senior engineering team treats this as an organizational question first, technical second, because that’s where most extraction decisions actually go wrong. On one client engagement involving a growing platform with dozens of internal tools, the approach was to consolidate around a modular architecture rather than fragment into services the team wasn’t staffed to run. Senior involvement from the first conversation meant migration risk got flagged before code was written, not after a rewrite stalled. Ongoing monthly support then kept the system healthy without requiring a dedicated platform team the client didn’t have.

Why “Monolith-First” Still Beats the Industry Hype

The conventional wisdom on this topic got warped by survivorship bias. Everyone remembers Netflix and Amazon talking about microservices at conferences; nobody remembers the hundreds of teams that copied the architecture without the traffic, the headcount, or the platform investment to support it. Amazon didn’t start as microservices. It became one after years of monolith growing pains, and only once its organization had genuinely outgrown a single deployable unit.

The gap I keep seeing is between what microservices promise and what teams are actually staffed to run. A 20-person startup adopting nine services isn’t buying scalability, it’s buying nine things to keep patched, monitored, and paged on, usually without anyone whose job is exclusively to do that. The distributed-system tax doesn’t ask permission. It shows up in slower feature delivery within two quarters, almost every time.

If you take one thing from this, it’s to treat team size and organizational readiness as the gate, not enthusiasm for the pattern. A modular monolith isn’t a consolation prize. For most companies, it’s simply the correct architecture, indefinitely.

, Davide Morotti

Get an Honest Architecture Review Before You Split Anything

Ampersand Labs is the alternative to guessing your way through an extraction decision: senior engineers review your actual codebase and team structure before recommending anything, instead of defaulting to whatever architecture is trending. That matters because the cost of getting this wrong isn’t theoretical. Teams that extract too early spend the next year paying the distributed-system tax instead of shipping features.

Architecture reviews can look at your bounded contexts, your CI/CD maturity, and your team’s actual capacity for platform work, then recommend a modular monolith build, a scoped migration, or targeted service extraction where the data actually supports it. For teams already past that point, ongoing monthly support can cover the operational load that microservices create without requiring you to hire a full platform team. Senior involvement from the first call means you get a straight answer about whether you need to split anything at all. Start with a technical audit or a short discovery call to find out where your architecture actually stands.

Sources

• Microservices, Martin Fowler
• Monolith vs Microservices: Team Topology, Conway’s Law, and the Distributed System Tax, The HLD Handbook
• Architecting microservices, Microsoft Learn
• Microservices

FAQ

Are Monoliths Better Than Microservices?

Neither is universally better. Monoliths tend to win for smaller teams and early-stage products, while microservices pay off once an organization has outgrown a single release train and can staff the platform work required.

Is Amazon Monolithic or Microservices?

Amazon runs on microservices today, but it started as a monolith and migrated incrementally over years as its engineering organization and traffic grew, not as a day-one design choice.

What Is an Example of a Monolith?

A typical e-commerce app with one codebase handling product catalog, checkout, and user accounts against a single shared database is a classic monolith, and it’s how most successful products begin.

What Are the Three Types of Microservices?

Microservices are commonly grouped by function: domain services that own specific business logic (like billing or inventory), integration services that connect to external systems, and infrastructure or platform services (like an API gateway) that support the others.

When Should a Startup Choose a Modular Monolith Over Microservices?

Most teams under roughly 30 engineers should default to a modular monolith, since they rarely have the headcount to staff the platform and observability work microservices demand.

Recommended

• Atelier Crincoli: A goldsmith’s whole workshop in one system, so no piece and no deadline goes missing.
• Interim CTO Zürich, Fractional & Part-time Tech Lead
• Habitects AG: Owning the tech side of a bathroom-renovation platform, all the way through a merger.
• Legacy System Migration & Replatforming Zürich