Microservices — One of the Most Expensive Mistakes at the Start

Microservices are one of the most overrated things in development. A team starts a project and immediately says, "let's break it into services, it will be scalable." Sounds logical. In practice, this is premature scaling, you are scaling something that doesn't exist yet. There's no load, no team, no problems. But there are already services, interactions between them, and infrastructure that someone has to maintain.

I had a specific example. We needed to create a recommendation system for an online store. The idea was to implement it as a separate microservice in Go, so that we could change the provider and keep it "flexible." The service accessed an external API, filtered data, and checked product availability. It took about three weeks.

In the next version of the backend, we simply implemented this within the main application in PHP. Without a separate service, without unnecessary infrastructure. And at that moment it became clear: the microservice was redundant. We thought "microservices = correct," instead of thinking: "does this solve the problem now?"

This does not mean that microservices are unnecessary. Here's the opposite case: we were receiving audio from clients in chunks, there was a high I/O load, and PHP objectively couldn't handle it. We moved one endpoint to a separate service in Python (FastAPI). This was justified: a specific problem, a technical limitation, a targeted solution.

Microservices are justified when there is a specific bottleneck, different types of load, the need for isolation, and a team to support it. There's no need to split the system into 10 services; often, one additional process is enough.

Microservices offer flexibility but come at a cost: development time, deployment complexity, monitoring, logging, network issues, data synchronization. Without DevOps practices and experience, you start spending more time on infrastructure than on the product.

The main question is always the same: is this needed now, or is it a fear of the future? Developer maturity is not about building complex systems. It's about not complicating things without reason.