My microservices origin story
I used to roll my eyes every time someone mentioned microservices. “Just use a monolith,” I’d say. “You’re overcomplicating things.” And for years, I was right. Most startups don’t need microservices. They need working features.
But then my side project grew. What started as a simple REST API became something bigger. Multiple teams, different deployment cycles, and one database that everyone was afraid to touch.
When the monolith starts breaking
The problems crept in slowly. One team needed to deploy a small bug fix. Another team was in the middle of a major refactor. Deployments became a negotiation. We started scheduling “code freezes” around holidays.
We had one shared database, and queries were getting slower. Adding indexes felt like performing surgery on a patient who was still awake. Every change had ripple effects.
So I ate my words
After much hesitation, I split our monolith into three services. It wasn’t easy. There were integration challenges, network failures to handle, and a lot of refactoring.
But here’s what nobody talks about: it was also liberating. Teams could move faster. We could scale individual services. The database anxiety disappeared.
What I learned
- Monoliths are fine until they’re not. Don’t microservices because it’s trendy. Do it when the pain becomes real.
- Start with a modular monolith. Clean boundaries inside a single codebase save you from many headaches later.
- Don’t forget the operational overhead. Distributed systems bring distributed problems. Monitoring, logging, and deployment get more complex.
The take
My stance softened. I still think most projects shouldn’t touch microservices. But I’ve stopped being dogmatic about it. Sometimes the monolith is the right choice. Sometimes it’s not.
Technical decisions should be driven by actual problems, not ideology. That’s what I keep reminding myself.