Design Pattern for Microservices -Part 03
As we discussed on Microservice architecture services should be independent and do not depend on any other services or one service’s functionality must not affect other services. But also when it comes to a scenario like new feature adding, updating, bug fixing one service must not halt other or one service’s development must not be limited by other services. But what happens when a new update of a certain service will affect the other services which are getting service from the updated services and how to avoid breaking down the system? There is a design pattern that can use with microservice to avoid services from breaking.
Proxy Service Pattern
As discussed above there might be changes where it affects other services, at that time rather than completely rewriting the entire new service to support to new version and to keep the application running without downtime developers can use a proxy service pattern. this approach will buy time for the other team to develop and release a new service as long as they need.
How proxy service patterns solve this problem is in a similar approach to the aggregation pattern. Instead of an aggregator both of the requests reached a “proxy”. When the request reaches a proxy service, it decides based on the version or request which this service request should pass, and with new API calls related to the new service directed to new service and other will fulfilled by the old proxy service. With the proxy, however, there are few important things to consider.
- Versioning - When it comes to maintaining proxies or different versions of services it is necessary to have proper API versions based on a system like semantic versioning. This will help the developers to understand what were the ongoing change and based on the version can their services break or incompatible before integrating or communicating with other services.
2 . Documentation - API documentation is the best way to given an understanding of the service to other developers who are not taking part in the development in service. this includes parameters, response, request, and everything about API endpoints before making an API call.
3. Service Discovery - When it comes to the services it is natural in Microservices to start new services or stop current running services based on usage or even due to crashes. But when the service went offline and back online there is no way that developers can keep an eye on it and put newly created services IP into a proxy service and remove the nonavailable IPs and hostnames. instead of that not only for the proxy pattern but also for services in Microservice architecture developers introduced a way called service discovery where developers can register their services in a service registry and each time when a service comes online registry will update with its hostname automatically.
