A Letter to My Past Self About Microservices

In 2017 I had a job that I was, by every reasonable measure, bad at. I was a tech lead, I had a team of five engineers, and the company had just raised a Series B with the explicit promise that we would, and I quote one of the slides, “re-platform on a microservices architecture” by the end of the year.

Reader, we did it. We re-platformed. We took an honest, slightly creaky monolith and we cut it into thirty-two services, each in its own repo, each with its own pipeline, each with its own on-call rotation. It took fourteen months. It worked, in the technical sense that it ran. It also nearly killed the product, the team, and most of my friendships.

The five regrets

1. We split services along organizational lines, not data lines.
2. We assumed that latency between services was free, and built every feature like an RPC.
3. We did not build a real platform team for two years.
4. We never wrote down the contract between services. We are still paying for that.
5. We wrote new tools instead of using boring ones.

Microservices are an organizational pattern that pretends to be an architectural one.

If I could go back, I would not undo microservices. I would just slow down. We had three or four services we should have built. The other twenty-eight, we should have left alone. The cost of an additional service is, in my experience, roughly the cost of a part-time engineer, forever. We had thirty-two of them. You can do the math.

I am writing this in 2026 and the team has, I am told, consolidated back to nine services. They claim it took eighteen months. I believe them.