We started hearing about microservices around 2014, when Martin Fowler and James Lewis wrote about it. The idea made sense: small services, independent deployments, better time to market.

Then every new project wanted microservices. The word looked sexy on a resume, and nearly every interview included it. If you were still building a monolith, you were made to feel behind.

Looking back, we pushed microservices to the extreme, and extremes lead to bad places.

What happened

Every new project started with 20+ services. We embraced the idea that each service must own its data, meaning each service had its own database. Those who split the logic but kept one database ended up with a distributed monolith.

We also liked the idea that each service could use its own tech stack. That’s how it was marketed to us. I’m guilty of pushing for it in one organization using the same thinking.

When it came to decomposition, we did a one-to-one mapping. If we had a product menu in the UI, then we assumed we must have a product service. Another service for discounts, another for shipping rates.

We ended up with distributed systems where things that should have lived together were now spread across services, databases, and teams.

The main problem

Things are fine after the initial deployment to production. Then comes the change request.

A change that should take normal time now crosses multiple services and teams. The product owner has to coordinate with other product owners. Each team has its own cadence.

Then the HTTP requests go from service to service to complete a single operation. Or we introduce a message broker to pass messages across services that should have been together in the same process.

A better way

There is a law that says something like: your architecture is a mirror of how your organization communicates. It’s called Conway’s Law.

If you don’t look at how your teams are organized, and how they communicate, how are you going to decompose your system? Start from the ground. The ground is how your teams communicate.

There is a team responsible for the catalog. Then product, category, discounts go into the same service.

There is another team responsible for finance. There is no reason to split that into multiple services under the same team, unless there is a specific need like unique resource demands (e.g., high CPU/GPU).

Eventually, you stop using the word micro. There is no such thing as microservices. There is a service that offers a value.

Current status

We have finally admitted that microservices are primarily an organizational tool. They solve the coordination problem between people, allowing teams to work independently. They are a solution to human scaling, not necessarily technical performance.

The default is to start with a modular monolith. You start with one codebase. Multiple teams work on it, but each team owns a module. That way they don’t step on each other. You see how things evolve. You see where the boundaries actually are.

Over time, those modules stabilize. You stop moving things around. The responsibilities become clear.

That’s when you say: this module can live on its own. Now it makes sense to split it into a separate service, with its own team, repo, and deployment. The split is a result of stability, not a starting point.

The takeaway

Starting with microservices was the mistake. We split systems before we understood the boundaries, and we paid the distribution tax.

Build the monolith first. Let the boundaries become clear. Then split when it is justified.