Lasha's blog

My Journey with Microservices

tl;dr: Do not move to microservices only because it is popular. Stay with your monolith as long as you can. Microservices are not a trophy. They are survival gear you will need when your business grows and the old system cannot keep up anymore.

Why Not Start with Microservices?

Let me be direct: you do not need microservices in the beginning. If your product is new, the only thing that matters is speed. You must release features, close the gap with your competitors, and find your place in the market.

Every hour spent on “fancy architecture” is an hour you could use to build what customers actually want.

But when the business grows, the situation changes. You have revenue. You start hiring. You onboard many SMB customers. Suddenly, you notice:

This is the moment the monolith starts to feel heavy. You cannot move forward easily. That is when microservices stop being “cool” and start being necessary for survival.

And even then—you do not rewrite everything in one day. It is a slow process. You take small, careful steps.

The Architect’s Promise (and Warning)

When the company is ready, usually the Enterprise Architect arrives with a big smile and a bigger slide deck. They talk about the dream world of microservices:

It sounds amazing, right? Like a new toy box.

But then comes the darker slide. The “small text” part:

So, the truth: moving to microservices is not only about code. It changes how the whole company works.

The Strangler Pattern

We did not blow up the monolith in one shot. Instead, we used the Strangler Pattern.

The name sounds scary, but it is friendly: you slowly move functionality out of the monolith until one day it is gone. Like pulling weeds in your garden—bit by bit, until only the new plants remain.

Steps look like this:

  1. Find a part of the app that you can move.
  2. Create a new microservice for it.
  3. Build a facade or gateway so old and new parts both work.
  4. Move more traffic to the new service step by step.
  5. Delete the old code when the new service is ready. (Best feeling ever.)

Example: Customer Service

We started with the customer management module. We created a new Customer Service with its own logic and data model. Then we used an API Gateway—basically a traffic cop—to decide where requests should go: monolith or new service.

At first, most requests still went to the monolith. Later, as the service grew, we redirected more traffic. Finally, all customer requests went to the new service, and we deleted the old code. That day felt like cleaning your desk after months of mess.

Testing and Data

Slow, sometimes painful—but safe.

How Services Talk

Splitting services is easy. Making them talk without fighting? Harder.

REST APIs

For direct calls, we used HTTP/REST. Each service had its own API. An API Gateway (Kong) managed them all and gave one entry point. Like a receptionist—knows who to call, so you don’t run around the office yelling.

Kafka Events

For async communication, we used Apache Kafka. Think of it as a group chat where services gossip.

Example: Customer Service updates a profile → it posts CustomerProfileUpdated. Notification Service and Fraud Detection Service both listen and say, “Thanks, I’ll handle it.” The best part? They don’t even know each other exists. It’s office gossip without the drama.

Kubernetes

To run all this, we used Kubernetes. DevOps wrote YAML manifests (basically magic scrolls) that described how services should live in the cluster. These files were in version control, went through CI/CD, and boom—infrastructure as code.

Governance and Observability

When you have many services, you need rules. Without rules, you get chaos.

And not only rules—also tools:

The SRE team also defined SLOs (availability, latency, quality). Sometimes they even released Chaos Monkey into production just to see what breaks. It feels crazy, but it teaches the system (and the team) how to survive under stress.

The Work Never Ends

Microservices are not a project you finish. They are continuous work:

It is never “done.” Microservices mean constant learning and change. And yes, sometimes frustration too. Coffee becomes your debugger.

Lessons Learned

After this journey, here is what I can say:

At the end, microservices are just another way to say: the system is too big for one team or one brain to manage alone. And that is actually a good problem to have.