Imagine a scenario where we have several development teams working on different microservices of the same application. These microservices have some communication between them; there is a kind of contract between them that is the payload of the microservice, also known as the Service Signature. One of the development teams modifies the signature of the microservice causing errors in other parts of the application.

As previously stated, modifying microservices is common, especially if they are part of the internal layer. When a microservice has the signature changed, a task must be generated for the other development teams responsible for microservices that integrate with this signature.

The problem is not the change, but the lack of information. The error was generated because the responsibility of notifying the teams that integrate with the microservice signature was a human responsibility, which is liable to failure and forgetfulness.

The signature tests work for possible alert changes in microservices payloads. There are many ways to do this, from webhooks to version control repositories, or even scripts and CIs.

Take the communication between RecommendationService and UsersService as an example. There is a common file for creating an RPC client/server communication model between the two microservices. This file is in the ProtoFiles repository and is called user_data.proto. In this case, the validation is very simple; just check whether this file has been modified.

To validate any changes to the user_data.proto file, the following command is enough:

$ git diff --name-only HEAD HEAD~1 | grep user_data.proto

This command validates whether there is any difference in the file between the current commit and the previous commit. Moving the command to a CI and creating a validation script is enough to apply signature tests in this case.