Stop reaching for microservices. You are not Netflix | Diogo Capela

Stop reaching for microservices. You are not Netflix<br>June 17, 2026

A few years ago, I watched a three-person team spend three months migrating a working Node.js monolith into several microservices. They had around 400 monthly active users. By the end of it, deployments took longer, debugging had become an archaeological dig across log aggregators, and shipping a feature that used to take an afternoon now took a week of cross-service coordination.

They shipped less. They paid more. They were proud of the architecture.

This is the trap. Microservices have become the default "serious" architecture in a lot of developer circles, copied from blog posts written by engineers at Netflix, Uber, and Amazon, then dropped directly onto products that have nothing in common with those companies. If you're a solo dev or a small team, I'm going to be blunt: you almost certainly don't need them, and reaching for them early is one of the most expensive mistakes you can make.

The blog posts you're reading were written for a different problem

When Netflix talks about microservices, they're solving for thousands of engineers working in parallel, hundreds of millions of users, and the cost of a single bad deploy taking down a global streaming service. Uber's architecture exists because they have specialized teams that need to ship independently without coordinating with everyone else. Amazon famously broke things apart because they hit organizational scaling limits, not technical ones.

None of that is your problem. Your problem is shipping a feature this week, fixing a bug your three users reported, and keeping the hosting bill under what you charge in MRR. The architectural pattern that solves "500 engineers can't merge to main without conflicts" is not the same pattern that solves "I want to add Stripe checkout by Friday".

What you actually pay for

Microservices aren't free. The price tag isn't on the AWS bill (though that's part of it) it's hidden in places that don't show up until you're already committed:

Operational complexity : Every service needs its own deployment pipeline, its own monitoring, its own logging, its own error tracking, its own runbook. Multiply that by seven services and you've just signed up for a part-time DevOps job you didn't have before. Hope you like writing Terraform.

Network failure modes : A function call that used to be a single in-process invocation is now an HTTP request that can timeout, return a 503, get partially completed, hit a retry storm, or fail because someone's IAM role expired. Distributed systems introduce entire categories of bugs that don't exist in a monolith, and most small teams have no idea how to debug them.

Data consistency : As soon as your data lives in separate databases, a single operation can no longer be one clean transaction that either fully succeeds or fully fails. Now you're stitching state together across services, handling the half-finished cases, and hoping nothing drifts out of sync. Your users don't care about any of that. They care that their order shows up.

Cognitive load : A monolith you can hold in your head. Seven services with their own repos, dependencies, versions, and deploy schedules, you cannot. Every new feature now requires you to figure out which service it belongs in, whether it crosses boundaries, and how to test the integration. That's all time you're not spending on the actual product.

Deployment velocity : Which is the cruel irony of the whole thing. People adopt microservices to ship faster. Small teams almost always end up shipping slower, because every cross-cutting change now requires coordinated deploys across multiple repos.

"But what about scaling?"

Here's the thing about scaling: you don't have a scaling problem. I promise. If you're reading this post, you do not have a scaling problem. A boring Postgres database on a $40/month VPS will comfortably handle more traffic than 99% of indie products will ever see. A modern Hetzner box with a few cores and decent RAM can serve millions of requests a day if you don't do anything stupid.

Premature optimization at the architectural level is the most expensive kind of premature optimization, because you can't easily back out of it.

If you do hit a real bottleneck (and you'll know, because something will be on fire) you can extract one service from your monolith at that point. That's the move. You don't need to start there.

When microservices actually make sense

I'm not saying microservices are bad. I'm saying they're a tool that solves specific problems, and those problems are rarely yours. The legitimate reasons to reach for them are mostly organizational, not technical. For example:

Multiple teams that need to ship independently and are stepping on each other in a shared codebase. This is real, but you probably have one team, or you are the team.

Genuinely different scaling profiles . One part of your...