The last aspect of reliability is engineering for continuous evolvement of the microservices. Often, services have multiple clients and refactoring drives. During this course, the advertised contract (or spec) of the service changes. However, not all clients can move to the new version of the contract at the same time. Improper updates/deprecation of APIs/contracts is an often-ignored cause of instability and unreliability in microservice-based architectures.

The way to insulate your clients is through proper versioning of the APIs. Generally, this happens by adding a version number to the API URLs, like so:

/v1/hotels/add   
/v1/hotels/search   
/v1/hotels/<hotel_id>   
/v1/hotels/<hotel_id>/book   
..   

When a new contract is needed to be deployed, we just upgrade the version and deploy the new routes effectively to the web servers and LBs. It is necessary for all the versions to be served from the same set of web server instances; the LB can route old versions to an older deployment so that the new code does not need to carry the baggage of old code.

In the next section, we will study reliability verification and the types of tests involved in it.