How do I guarantee that the interface between two microservices is not broken?

Question

Imagine we have two microservices: client and server. One of the most fundamental features of microservice architecture is an ability to have a separated pipelines for each microservice meaning that we have to be able to deploy them to production independently.

This implies that different microservices may be developed by different teams and some of the features are developed faster on one microservice than on the another. This quite often ends up with the contract (interface) being broken between client and server, so the JSON that the client sends to the server is no more valid.

The question is how to prevent cases where communication between two microservices is broken due to a broken contract between them? What is the best strategy to handle such issues?

Answer 1

The question is how to prevent cases where communication between two microservices is broken due to a broken contract between them?

1. Design of Contract: While you are designing the contract, the server [also called service provider or producer] can not dictate the contract and just say here is the contract for my offering and now go and consume the service. If server has multiple clients (which is usually the case), then multiple clients will give their 'demands' for contracts and server will then implement the minimal common aggregate as service offering.

2. Change In Contract: Service provider should strive to keep the contract as backword compatible in most of the times. However, if contract requires significant change, then it can be handled with spinning up new version of endpoint. In this case, decommissioning of old endpoint of service(e.g. say v1) will not be done immediately. Consumers of service are given notice of this change and given some time to switch over to newer version of contract. (eg. say v2)

You can get more infomration on Martin Fowler's bliki: https://martinfowler.com/articles/consumerDrivenContracts.html

What is the best strategy to handle such issues?

I think,I have answered the strategies above. However, in terms of tooling, following are some tools that will facilitate the scenario:

1. Pact: https://docs.pact.io/
2. Consul:This is service discovery tool, however, if you are adopting microservices, then this will be really useful for dealing with numerous services. https://www.consul.io/

Answer 2

One solution is endpoint versioning. Assuming your microservices are REST APIs, you can instruct your teams to increment versions of API endpoints if any change they would make to that endpoint would break it. Follow a cycle of deprecation and after 6 months remove support for the older endpoints. It gives you time to switch over to the newer versions and not break anything relying on the older versions.

Another solutions is, instead of microservices talking to microservices, have an orchestration layer. That is, some manager of microservices which abstracts away any microservice to microservice communication. The applications which would be consumers of microservices then become consumers of the orchestration layer, which determines which microservice api's need to be called. This still ends up causing broken contract issues if the API contract is changed, but you can fix it at the orchestration layer where it is all centralized instead of coordinating cross team microservice changes.