There's a particular kind of prestige that comes with saying your system is microservices-based.
It sounds serious. It sounds like the kind of thing Amazon does. It implies scale, sophistication, a team that has outgrown simple solutions. Engineers who've worked on microservices put it on their CVs. Teams that adopt them feel like they've levelled up.
Most of them would build better software on a monolith.
How we got here
The narrative around microservices came from the right places. Netflix, Amazon, Uber — organisations with hundreds of engineers and millions of users — described how decomposing their systems allowed teams to move independently, deploy without coordination, and scale individual components under different load profiles.
The architecture made sense for them because of who they are: enormous organisations with the headcount to staff each service, the platform investment to support it, and genuine scale problems that a single deployment couldn't handle.
The rest of the industry heard "microservices work at scale" and concluded "microservices will help us scale." That's not the same thing. That's not even close to the same thing.
What microservices actually cost
Every service boundary is a tax. You pay it every time you ship a feature that crosses it — which, in a small system, is almost every feature.
Network calls where function calls used to be. Distributed tracing to understand what's failing and where. Service discovery, health checks, retry logic, circuit breakers. Running a local environment means running twelve containers that need to start in the right order and talk to each other correctly. Debugging means correlating logs across four different dashboards.
For a team of five engineers, this overhead doesn't buy you anything. You're not running different services at different scale. You're not deploying teams independently — you are one team. You've taken on the operational complexity of a large organisation without any of the benefits that complexity was designed to unlock.
And the junior engineers on your team? They can no longer understand the system. They need the person who knows service seven to be available before they can work on service eight. The bus factor goes up. Velocity goes down.
The monolith isn't embarrassing
At some point, "monolith" became a slur. Something to apologise for. A sign that you haven't modernised.
Basecamp has run on a Rails monolith for twenty years. Shopify ran on a monolith through enormous growth before carefully decomposing parts of it. Stack Overflow serves millions of requests from a monolith on a surprisingly small number of servers.
A well-structured monolith — clear module boundaries, good separation of concerns, a disciplined team — can take you further than most startups ever need to go. It's easier to understand, easier to test, easier to deploy, and dramatically easier to reason about when something breaks at 2am.
When microservices make sense
They make sense when a specific part of your system has genuinely different scaling requirements from the rest. When a team owns a surface area end-to-end and operates it independently. When the organisation is large enough that the coordination overhead of a shared codebase exceeds the coordination overhead of service contracts.
None of those conditions apply to most teams adopting microservices. They do it because it feels like the right thing for a serious engineering team to do.
The serious engineering teams I respect most are the ones who ask whether the complexity is earning its cost — and who are not embarrassed to answer no.
Start with the simplest thing that works. Break it apart when the pain of not doing so is real. Not before.