The question is how to prevent cases where communication between two microservices is broken due to a broken contract between them?
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.
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:
- Pact: https://docs.pact.io/
- 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/