Microservices are not always the answer
I work with microservices daily. I like them. But I also remember when a monolith would have saved us weeks.
I work on a platform with 15+ services. Kafka between them. Separate deploys. The whole thing.
And sometimes I think: this specific thing would have been faster as one service.
When they make sense
Our GPS platform genuinely benefits from microservices. The gateway handling TCP connections has completely different scaling needs than the event detector crunching business logic. One is I/O bound, the other is CPU bound. Separate scaling, separate deploys, separate failure domains. Makes sense.
When they don’t
I’ve seen teams (including past me) split things into services too early. Two services that always deploy together. That share a database. That can’t function independently.
Congratulations, you now have a distributed monolith with network calls instead of function calls. Slower, harder to debug, same coupling.
My rule now
Start with one service. Split when you feel pain. Not when you feel clever.
Pain looks like: “this thing needs to scale independently” or “this team needs to deploy without waiting for that team” or “this failure shouldn’t take down everything else.”
Clever looks like: “microservices are best practice” or “what if we need to scale this someday.”
The debugging tax
Every network boundary is a place where things can fail silently. Every async message is a thing that can get lost, duplicated, or delayed. Every separate service is a separate set of logs to correlate.
I’m not saying don’t use them. I’m saying know what you’re paying for.