How microservices should expose their API interfaces

Running Microservices in isolation does not make any sense; it is natural for them to work together and solve a bigger problem. This would require each microservice to expose a well-defined API interface simplifying others to talk to it.

The following are the best practices that we should follow that would make interfacing and integration easy.

Forward and Backward Compatability

While rolling out any changes in a microservice, we need to ensure they are both forward and backward compatible. If not, it would break the consumers or interfacing microservices.

Three key places where we need to be extra careful are

• while changing the database schema
• while changing the API response body
• while changing the message format in async communication

We can ensure forward and backward compatibility if we

• never abruptly delete any column/attribute
• never abruptly change the type of the column/attribute

We should always roll out breaking changes in phases ensuring the dependent services remain unaffected.

Make APIs tech-agnostic

Tech evolves quickly in the world of software engineering, and hence we would always feel like using the new shiny thing available. While having that urge, we should always ensure we are not picking the technology that would induce tight coupling.

For example, we should not pick a framework that would require the interfacing services to be written in a particular language or require them to use a specific tech stack. This would take away autonomy from the interfacing services as we are dictating which stack to use.

Dead simple consumption

Microservices are built to interact with other services and get things done. So, the core focus should be to make things super simple for anyone to integrate.

It does not matter how good your LLD is if the API interface is hard to integrate. Be consumer-centric while designing the interface of a microservice and ensure you have

• simple API
• simple data format
• use common protocols

Hide internal implementation details

Never let other microservice learn about the internal implementation detail of your service. If they interact using internal details this would create a tight coupling between the two services.

Internal details could be

• broker for internal communication
• building dependency on transitive dependencies
• allowing directly connecting to the private database

It is always safe to hide the internal implementation details and expose a strict interface to interact with the service. The interface could be REST, gRPC, or anything that your org uses.

Here's the video of my explaining this in-depth ?? do check it out

Running microservices in isolation does not make any sense. To get something done, multiple microservices need to talk to each other and put a task to completion. This requires the services to interface with each other.

How would the services interface and integrate? is there a common way to do it?

In this video, we talk about 4 best practices we should follow while designing microservices to encourage inter-service integration. These practices would help us keep interfacing simple, easy, and intuitive.

Outline:

• 00:00 Agenda
• 02:36 Introduction
• 03:00 Backward and Forward Compatability
• 06:29 Make API interface tech agnostic
• 09:01 Dead simple consumption
• 11:00 Hide internal implementation details

You can also

• Subscribe to the YT Channel Asli Engineering
• Join my Telegram Channel Asli Engineering on Telegram
• Download the notes
• Listen to this on the go on Spotify

Thank you so much for reading ?? If you found this helpful, do spread the word about it on social media; it would mean the world to me.

You can also follow me on your favourite social media LinkedIn, and Twitter.

Yours truly,

Arpit

arpitbhayani.me

Until next time, stay awesome :)

I teach a course on System Design where you'll learn how to intuitively design scalable systems. The course will help you

• become a better engineer
• ace your technical discussions
• get you acquainted with a massive spectrum of topics ranging from Storage Engines, High-throughput systems, to super-clever algorithms behind them.

I have compressed my ~10 years of work experience into this course, and aim to accelerate your engineering growth 100x. To date, the course is trusted by 600+ engineers from 10 different countries and here you can find what they say about the course.

Together, we will build some of the most amazing systems and dissect them to understand the intricate details. You can find the week-by-week curriculum and topics, benefits, testimonials, and other information here https://arpitbhayani.me/masterclass.