Scaling Via APIs

Problem

"I started working for Trustpilot as an engineer when it was still a small startup. It didn't have any tech founders, so the first part of it was built by consultants, and then young, fairly inexperienced engineers, including me, were brought in to continue building code. We ended up with a big monolith, and as our company grew our services didn't scale. Just as bad, while the monolith continue grow bigger and more complex it became even more difficult to get new engineers onboarded."

Actions taken

"We didn't have time to waste, we needed to hire, so we continued to hire aggressively. I started research to figure out how to solve the two problems, and eventually decided to start implementing microservices and APIs to a knowledge stack. We did this in an untraditional way. Usually, people start doing this by building a very flexible API. However, we decided to build one API to rule them all. It wasn't flexible, but was able to be built very quickly, and within a few months we had encapsulate our monolith with APIs. This then allowed us to tell of our teams to only use APIs to build new features while we set a few teams aside to migrate the old monolith out to microservices. As part of this we also set the foundation to be able to example re-write or re-plaform small pieces of the product without having to cover it all at ones. It enabled us to put focus on the areas that had the biggest problems first."

Lessons learned

"Look for opportunities where you can solve organizational issues with architecture. By doing this, we were able to separate our codebase into smaller, more manageable services with less complexity. We managed to build a setup were engineers become productive faster, enabling us to grow with the demand and to have independent teams that had the control of the technology needed to for their services to work best. Note: Were I have seen it very effective combining architecture and organizational challenges, it's not the case when combining feareus and re-platforming/re-architecture. Properly the most important engineering principle in my book is never to combine adding features and re-platforming at the same time. Seperate those two I have experienced always to deliver faster."