Why should we have a standard way of building Microservices?

631 views Designing μ-services

We all love creating microservices, but there should be a standard way of creating them?

If we give complete autonomy to engineers to build their services then we will end up with the chaos of languages, frameworks, tools, and conventions. Hence standardization becomes essential to limit the chaos.

Standardization allows us to keep the entire system coherent and uniform and the 3 verticals that need standardization are:


Monitoring one microservice is relatively a simpler problem, and with easy-to-integrate tools, it becomes a breeze. Few examples

  • logging tools - ELK or EFK
  • APM tools - NewRelic or DataDog
  • status code monitoring on cloud consoles

Monitoring how a request originates from the user and goes through various services is important and this problem of Distributed Tracing can be solved through tools like Zipkin and AWS X-Ray.

Microservices need a standard way of reporting key metrics like CPU, Memory, Disk, and App Metrics into a central system like NewRelic or CloudWatch allowing everyone to get the necessary transparency.


There are 100s of ways through which the microservices could talk to each other. This demands standardization and we need to consolidate on a few ways of interfacing.

Consolidating to REST for user-to-service communication and gRPC for service-to-service communication seems to be the most popular choices. But it is totally up to you to pick the ones.

We cannot allow the communication to happen over a variety of formats and hence we need to consolidate on a few like - JSON and ProtoBuf.

We also need to standardize the nomenclature and how REST endpoints are written. This would ensure that the entire engineering team feels familiar while writing any inter-service communication.

Other aspects that need standardization are Versioning, Timeouts, and Retries. Having this standardization would allow us to write common libraries to abstract out the implementation complexities and save redundant efforts.


Every service needs to shield itself from getting bombarded. Standardizing the tolerance would save us redundant efforts and implementations. A common protection layer would not only prevent the service from getting overwhelmed but also ensure no cascading failures.

Some standard configurations could be

  • limit the number of incoming calls from a service
  • ability to cut off incoming and outgoing requests from/to a service

Such abilities would help us reduce outage times and prevent cascading failures as engineers would be aware of exactly what to do to cut off.

Arpit Bhayani

Arpit's Newsletter

CS newsletter for the curious engineers

❤️ by 17000+ readers

If you like what you read subscribe you can always subscribe to my newsletter and get the post delivered straight to your inbox. I write essays on various engineering topics and share it through my weekly newsletter.

Other essays that you might like

BFF - Backend for Frontend - Pattern in Microservices

2225 views 114 likes 2022-07-04

As your application evolves, supporting multiple types of clients like Desktop, Mobile apps, etc becomes tricky. The bac...

Best practices that make microservices integration easy

850 views 50 likes 2022-06-27

Running microservices in isolation does not make any sense. To get something done, multiple microservices need to talk t...

Things to remember while building Microservices

856 views 35 likes 2022-06-20

An engineer working on Microservices should not only just focus on engineering; there are so many other aspects to look ...

Why should we have a standard way of building Microservices?

631 views 27 likes 2022-06-17

We all love creating microservices, but what if every team creates its own microservice uniquely and uses its own conven...

Be a better engineer

A set of courses designed to make you a better engineer and excel at your career; no-fluff, pure engineering.

System Design Masterclass

A masterclass that helps you become great at designing scalable, fault-tolerant, and highly available systems.

Enrolled by 700+ learners

Details →

Designing Microservices

A free course to help you understand Microservices and their high-level patterns in depth.

Enrolled by 17+ learners

Details →

GitHub Outage Dissections

A free course to help you learn core engineering from outages that happened at GitHub.

Enrolled by 67+ learners

Details →

Hash Table Internals

A free course to help you learn core engineering from outages that happened at GitHub.

Enrolled by 25+ learners

Details →

BitTorrent Internals

A free course to help you understand the algorithms and strategies that power P2P networks and BitTorrent.

Enrolled by 42+ learners

Details →

Topics I talk about

Being a passionate engineer, I love to talk about a wide range of topics, but these are my personal favourites.

Arpit's Newsletter read by 17000+ engineers

🔥 Thrice a week, in your inbox, an essay about system design, distributed systems, microservices, programming languages internals, or a deep dive on some super-clever algorithm, or just a few tips on building highly scalable distributed systems.

  • v12.4.4
  • © Arpit Bhayani, 2022

Powered by this tech stack.