https://www.youtube.com/watch?v=4F0dlOMWGHE
Monolith or microservices? You've been in this meeting before. One engineer says "we need to move to microservices or we won't scale." Another one says "we tried microservices at my last company and it was a disaster." Both of them think they're arguing about architecture.
They're not. They're arguing about Conway's Law, and neither of them has noticed yet.
Here's the one-sentence version of what every balanced treatment of this topic is actually trying to tell you: microservices pay off when multiple autonomous teams need to deploy independently across cleanly separable domains. Otherwise, a monolith is cheaper. Everything below is the detail.
Microservices aren't about services
The most common definition you'll hear — "a microservice is a small service" — is wrong. Size is a symptom, not the rule.
A microservice is defined by one property: independent deployability. You can push one service without coordinating with the others. No shared database. No lockstep release. One team ships; nobody else has to wait.
If your services share a database, or they have to be deployed together, or a change to one requires a change to another — you don't have microservices. You have a distributed monolith. That's strictly worse than a regular monolith, because you've paid the distributed-systems tax and gotten nothing back.
So the question isn't "do we want lots of small services?" It's "do our teams actually need to ship independently?"
The case FOR, steelmanned
There are two things a monolith physically cannot do.
One: independent deploy cadence. If you have a pricing team that ships experiments five times a day, and a payments team that ships quarterly under compliance review, they cannot coexist on the same release train. One team's test suite is the other team's blocker. In 2002, Amazon figured this out and made a company-wide rule: no team communicates with another team except via service APIs. Every API had to be externalizable. The result, years later, was AWS as a business, and deploys happening somewhere around every eleven seconds.
Two: Conway's Law. Named after Melvin Conway, 1968: "Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure." Your architecture is a photograph of your org chart. You can't escape it. If you want autonomous services, you first need autonomous teams. Every successful microservices migration you've heard of is an org restructure in disguise.
That's the pro argument. It isn't "small services are better." It's: when your org has outgrown a single team's coordination ceiling, microservices are the tool that lets teams decouple from each other.
The catch is right there in the sentence: "when your org has outgrown a single team's coordination ceiling." Most teams haven't.
The case AGAINST, steelmanned
Two pathologies that microservices have and monoliths don't.
One: the math. Suppose each service call has a 99% chance of being fast. Now a single user request fans out to 100 services. What's the probability that at least one of those calls is slow?
P(at least one slow) = 1 - (0.99)^N
N=10 → 10%
N=100 → 63%
N=1000 → ~100%
63%. Two-thirds of your user requests hit at least one slow backend, not because anything is broken, but because probability scales with fanout. Jeff Dean and Luiz Barroso named this "the tail at scale" in a 2013 paper. In-process calls have latency variance too — but the network multiplies it across every hop. Fanout turns rare slowness into the common case. And you only see it in production.
Two: the distributed monolith. The most-named, least-visualized failure mode in the whole debate. You set out to build microservices. You end up with twelve services that call each other synchronously five-deep, share a database, must be deployed together, and can't be run locally. You paid every distributed-systems tax, and got none of the distributed-systems benefits.
That's the worst tradeoff in software architecture. And it's what you get when you adopt the architecture without the org structure that justifies it.
When each one wins
Three questions. Answer in order. Stop at the first "no."
- Do you have 15+ engineers across multiple autonomous teams contributing to the same codebase?
- Do those teams actually need to deploy at different cadences, and is the shared pipeline the real bottleneck?
- Can your product be genuinely split into separate domains that each feel like they could be bought from a different company?
Three "yes" answers → microservices earn their premium.
Any "no" → monolith, or modular monolith. Shopify runs a Rails monolith with over a thousand engineers and handles thirty terabytes per minute at flash-sale peak. Stack Overflow serves 200M+ requests a day off eleven web servers. These aren't companies that failed to graduate to microservices. They're companies that looked at the three questions and decided they don't have the organizational problem.
Here's the honest footnote. Martin Fowler popularized the word "microservices" in 2014. One year later, he wrote an essay called MonolithFirst. His line: "Almost all the successful microservice stories have started with a monolith that got too big." The same person who named the architecture also named the mistake of starting with it.
The verdict
Microservices solve an organizational scaling problem by introducing distributed-systems problems. If you don't have the first, you don't want the second.
Next time this debate starts at your company, don't argue about Netflix or Amazon. Write the three questions on a whiteboard. If the answers are "one team, no, and no" — you already have your answer.
Build the architecture that actually matches the team you have. Not the one you wish you had.
