Nanoservice is bad, really?

Microservice is a famous architecture that has been applied by many tech companies. It enables the rapid, frequent and reliable delivery of large, complex applications, and allows an organisation to evolve its technology stack. It seems to be a good architecture but a too small service can increase the overhead on communications, maintenance, and many more. A service that is too small or fine-grade is called a Nanoservice.

Some people say that Nanoservice is an anti-pattern because of the overhead in maintenance, communication, and so on. Well, It’s not wrong. I’ve seen people (including me) creating a new service with an unclear domain so it increases the complexity of development and maintenance.

I found a different story in Gojek, it’s a good use case for Nanoservice. Our Order Management System (OMS) for transport, a Jruby application, had more than 20 machines just to serve find order API (we call this FBON API). There were some improvements made but nothing significant until the idea to take out FBON API into a separate service came up. With moving FBON into a separate service, we have flexibility to decide the new tech stack for FBON. We decided to use Golang for FBON service since golang is well known for its performance.

We tested FBON service with the peak traffic and it resulted amazing results. The FBON API in FBON service required 5 machines only to serve the peak traffic while the FBON API in OMS required more than 20 machines. FBON service has been working for more than two years now and we found benefits with the decision to take out FBON API into a separate service.

Software Engineer | Architect | Manager | A father of two

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store