Microservices Are Overhyped
Why 90% of Companies Should Just Stick With a Monolith
I’ve lost count of how many companies I’ve seen rush headfirst into microservices like they’re the holy grail of software architecture. Everyone’s read the same blog posts, seen the same conference talks, and internalized the same mantra: “You have to break it down into microservices if you want to scale.”
Here’s the thing: that’s complete nonsense for the vast majority of teams.
Let me say it clearly—90% of companies should just stick with a monolith.
And I’m not talking about a messy, spaghetti-ball monolith where everything’s jammed together in one god-class. I’m talking about a well-structured monolith. A single codebase with modular boundaries, clean separation of concerns, and tests that actually run.
The benefits are obvious once you’ve lived through the pain of microservices:
Deployment hell. With microservices, you now need an orchestration layer (Kubernetes, Nomad, ECS, whatever) just to get the damn things running. That means YAML files for days, CI/CD pipelines that look like Rube Goldberg machines, and engineers who spend half their time debugging container networking instead of building product features.
Local dev misery. Want to run the app locally? Cool, just spin up 12 services, each with their own ports, configs, databases, and message queues. Hope you’ve got 32GB of RAM handy.
Overhead everywhere. You suddenly need service discovery, observability pipelines, tracing infrastructure, distributed logging, retry logic, backoff strategies, circuit breakers… congratulations, you’re now in the infrastructure business.
The myth of scalability. Most startups and even mid-sized companies never come close to hitting the scale that justifies microservices. They end up with more ops overhead than actual business logic. The bottleneck isn’t their database sharding strategy—it’s product/market fit.
I once worked at a company of maybe 20 engineers. We had less than 10,000 daily active users. Still, leadership decided microservices were the way to go. Within a year, we had an “auth service,” a “billing service,” a “user profile service,” and a “notifications service”—each with its own repo, pipeline, and database. Did it help? Nope. It slowed us down. A single feature like “send a user a receipt” required touching three repos, syncing schemas, and praying our staging environment wasn’t on fire.
Contrast that with another company I worked at where everything was in a single Rails monolith. We could build, test, and deploy a new feature in hours. One repo, one deploy, one place to debug. The speed advantage was night and day.
The reality is microservices are an optimization for very large companies—the Amazons, Netflixes, and Ubers of the world. They have thousands of engineers who would step on each other in a single codebase, and their scale demands distributed systems. They also have the budget to hire platform teams dedicated to taming the complexity.
You? You don’t.
For almost everyone else, a well-designed monolith will take you further, faster, and with far fewer headaches. Start there. If, by some miracle, you actually grow into the kind of scale where microservices make sense, you’ll have the engineering talent and money to peel services off when you need to.
But until then? Stop cargo-culting. Keep it simple. Stick with the monolith.