The Microservices Trap
I used to think microservices were the answer to everything. Small services,独立部署, easy to scale — what could go wrong? I pushed for microservices on three different projects in my first few years as a backend developer.
Now I look back and realize: for small projects, it was overkill. Big time.
What Actually Happened
We had a team of 4 developers working on a product that could have been a clean monolith. Instead, we ended up with 7 services talking to each other through APIs. Every deployment felt like conducting an orchestra where half the musicians were on lunch break.
One service goes down? Good luck figuring out why your checkout flow stopped working. Need to add a simple field? Cool, update the API contract, update three consumers, redeploy everything.
The Real Cost Nobody Talks About
- Operational complexity: You need monitoring, logging, and tracing across services. That’s extra infrastructure.
- Network latency: Service-to-service calls add up. What was a single database query becomes 3-4 HTTP calls.
- Debugging nightmares: Tracing a request through 5 services isn’t fun. It’s not even interesting — it’s just painful.
- More code to write: You’re basically writing boilerplate API code instead of solving actual business problems.
When Microservices Make Sense
I’m not saying microservices are bad. They’re great when:
- You have multiple teams that need to deploy independently
- Different parts of your system have vastly different scaling needs
- You’re building something that genuinely needs to be fault-isolated
What I’d Do Instead
For most projects under a certain size, I’d say: start with a well-structured monolith. Use packages or modules to keep things organized. Extract a service when you actually have a reason to — not because it’s trendy.
Your time is better spent solving business problems than managing distributed systems you don’t need yet.
The best architecture is the one that lets your team move fast. Sometimes that’s microservices. Usually, for small teams, it’s not.