Monolith vs Microservices: The Decision Nobody Talks About Honestly

A lot of developers architect for vibes.

Not for what their product actually needs right now, not for the team size they actually have, and not for the scale they've actually reached. They build for what sounds impressive in a system design interview, or for whatever the big companies are rumoured to be doing.

That is exactly why the monolith versus microservices debate online is so loud and so unhelpful. Everyone has a strong opinion, and most of those opinions come from what people read rather than what they've had to operate under real production pressure at 2 am.

So let me break this down the way I'd actually reason about it on a real team. I'll cover what each architecture really is, when each one genuinely makes sense, the tradeoffs that rarely make it into the blog posts, and where you see each used in the wild. By the end, you should be able to look at a product at any stage and know which one fits, based on what the system needs rather than what's fashionable.

First, what we're actually talking about

A monolith is a single deployable unit. Your entire application, including user auth, payments, notifications, and data processing, lives in one codebase and ships as one thing. One build, one deploy, usually one database.

Microservices are the opposite. The application is split into small, independent services, where auth is its own service, payments is its own service, notifications is its own service, and so on. Each one deploys independently, scales independently, and talks to the others over a network, typically HTTP or a message queue.

That single architectural difference is the whole story. Almost everything else people argue about is a downstream consequence of it.

The monolith deserves more respect than it gets

The monolith carries a reputation it hasn't earned. People treat it as a legacy mistake, the thing you reluctantly start with before graduating to "real" architecture. That framing is backwards.

A monolith is simple in the ways that matter day to day. One codebase means one place to look when something breaks. One deployment means you aren't choreographing releases across six services. One database means your data stays consistent without reaching for distributed transactions. For a solo developer or a small team, that simplicity isn't a compromise you're tolerating, it's a genuine competitive advantage. You ship faster, you debug faster, and you can hold the whole system in your head.

It's worth separating two very different things that both get called "monolith," because the distinction is where most of the bad reputation comes from.

A traditional monolith has no real internal structure. Auth logic calls payment logic calls notification logic, everything reaches into everything else, and it works fine right up until it doesn't. When it finally does break, untangling it is genuinely painful because there were never any boundaries to begin with.

A modular monolith keeps the single deployable unit but enforces clean internal boundaries. Auth, payments, and notifications each live in their own module with a well-defined interface, and the modules don't reach into each other's internals. You get the deployment simplicity of a monolith with the structural clarity of services, and crucially, without the operational overhead of a network sitting between every component. This is what I reach for on greenfield products: one deployable unit, clean internal seams, and any module extractable into a service later if a real need shows up.

Where the monolith wins

• Early-stage products where requirements are still moving. When you're still discovering what the product even is, refactoring a monolith is far cheaper than rewiring a fleet of distributed services every time your understanding changes.

• Small teams of roughly one to five engineers. The operational cost of microservices, which means monitoring distributed systems, running service discovery, and debugging network failures between services, demands dedicated infrastructure investment that a small team simply can't sustain without it eating all their time.

• Products where the bottleneck is feature velocity rather than compute. Most early products don't need to scale infrastructure, they need to ship fast enough to find product-market fit before the runway ends, and a monolith serves that goal directly.

The real-world track record backs this up. Shopify famously ran on a Rails monolith for years as it scaled to enormous transaction volume, Stack Overflow has long served huge traffic from a remarkably small number of servers, and Basecamp has stayed a monolith for the better part of two decades. None of these are technical failures, they're deliberate choices that let focused teams move quickly.

Where the monolith struggles

• Scaling under uneven load. When different parts of your application have wildly different resource demands, a monolith forces you to scale all of it together. Picture something like YouTube, where video processing is enormously compute-heavy while the user profile service sits nearly idle. In a monolith, you scale the entire application to absorb the video load, paying for compute, the profile path never touches, which gets wasteful and expensive fast.

• Team size. Once you have twenty engineers committing to the same codebase, you start collecting merge conflicts, deployment bottlenecks, and a test suite that takes forty minutes to run. The coordination cost of shared code eventually outweighs the simplicity benefit that made the monolith attractive in the first place.

• Independent deployment. When your payments team needs to push a fix in the middle of the night without touching the codebase everyone else is mid-flight on, doing that inside a shared monolith is genuinely risky.

None of these means you should avoid a monolith early. They're pressure signals to watch for, and when two or three of them start showing up together, that's the system telling you it's time to carve off your first real boundary.

Microservices, and the bill that comes with them

The appeal of microservices is real. Independent deployment, independent scaling, and technology flexibility, where each service can use the language and datastore that fit its job, are all legitimately valuable. The problem is that the appeal is usually sold without the full invoice attached.

When you split an application into services, you don't remove complexity, you relocate it from your code into your infrastructure. The hard problems don't vanish, they change shape.

A function call between modules takes nanoseconds and either runs or doesn't. A network call between services takes milliseconds and can fail in the middle, so now you're designing for timeouts, retries, and cascading failures. When your auth service goes down, every service that depends on it is suddenly in a degraded state you have to handle explicitly. In a monolith, that scenario was just an application crash. In microservices, it's a distributed failure mode you have to anticipate and engineer around.

Debugging changes character too. In a monolith, you have one log stream, one stack trace, and one process to inspect. In microservices, a single user request might pass through six services, so when something breaks, you're correlating logs and traces across six systems. That essentially requires distributed tracing infrastructure, usually OpenTelemetry for instrumentation feeding a backend like Jaeger, Grafana Tempo, or a hosted option such as Honeycomb or Datadog, which is now one more thing you own and maintain.

Deployment multiplies in the same way. Each service tends to want its own pipeline, its own image, its own health checks, and its own rollback story. For a three-engineer team, that operational tax is enormous relative to the value it returns.

Where microservices win

• Large engineering organisations where teams need to own separate pieces independently. Amazon restructured around services precisely because teams were forever waiting on each other inside shared codebases. Once you have hundreds of engineers, service boundaries double as team boundaries, and that organisational decoupling is where most of the real value actually lives.

• Systems where different parts have genuinely different scaling profiles. A ride-sharing platform like Uber runs location tracking that ingests millions of GPS updates per second, which has nothing in common, infrastructure-wise, with a payment reconciliation job that runs in overnight batches. Services let you scale each on its own curve instead of averaging them together.

• Cases that need real technology independence. A machine learning inference service in Python sitting next to a high-throughput ingestion service in Go is a legitimate reason to want per-service technology choices, rather than the resume-driven version of the same argument.

• Domains where failure isolation is a hard requirement. In financial and healthcare systems, a failure in one area must not be allowed to cascade into others, and carefully designed services give you that bulkhead in a way a single process can't.

The examples track the theory. Netflix is well known for decomposing large parts of its platform into hundreds of services over time, Uber moved toward a services architecture to manage geographic complexity and team autonomy, and Airbnb's service-oriented architecture lets its infrastructure, trust, and payments teams operate on their own. The common thread is that every one of these is about decoupling people or load at a scale most teams will never reach. That's the real tell: microservices pay off when the organisation, not just the codebase, has outgrown a single shared unit.

The honest tradeoff table

A rule of thumb you can actually use

If you want something concrete to hold a real decision against, this is roughly how I weigh it.

Reach for a modular monolith when:

• Your team is under about ten engineers.

• You're building one product on one deployment cadence.

• Requirements are still shifting week to week.

• Your bottleneck is shipping features, not serving load.

Start extracting services when:

• Multiple teams own different domains and keep blocking each other.

• One part of the system has scaling needs the rest genuinely doesn't share.

• Independent, off-cadence deployments have become a real necessity rather than a convenience.

• Organisational coordination, not compute, is the thing slowing you down.

If you find yourself squinting at both lists and most of your honest answers land in the first one, you have your answer, and it happens to be the cheaper one to live with.

The decision nobody actually states out loud

The real question was never "monolith or microservices." It's this: what is the actual bottleneck in my system right now, and which architecture relieves that bottleneck without creating five new ones?

For most products at most stages, the bottleneck is not infrastructure scaling. It's engineering velocity, the ability to ship fast enough to survive. A monolith solves that, so that's where you start. The right moment to introduce service boundaries is when a specific, measurable pain point demands it, and not a day before. Premature distribution is just premature optimisation wearing a more expensive suit, because you pay the full cost of the complexity long before you see any of its benefits.

The pattern that holds up in practice is to start with a modular monolith, and when one module's scaling or ownership needs genuinely diverge from the rest, extract that module into a service. Then repeat only when reality forces the issue. Netflix and Amazon didn't begin as microservices, they began as monoliths and peeled off services as scale demanded it.

So build for where you are, design for where you're credibly going, and stop architecting for where you wish you already were.interview or