A client consumes remote resources through servers with no expectation of errors or any performance drawbacks in common cases. What it should do if errors happen or in case of poor performance? How we should resolve these problems when a client needs a resource and tries to retreive it iteratively but each attempt ended in failure?
Answers can be hidden in resiliency patterns:
- Client-side load balancing
- Circuit breakers
- Fallbacks
- Bulkheads
Client-side load balancing
A client defines a destination of request routing by having information about service’s instances, their physical location. Before sending a request the client has to look up a server destination through client-side load balancer that already aggregate data about server instances.
Out of the box solution: Netflix Ribbon.
Server-side load balancing is more “famous” than client-side one. When a client sends a reqeust to backend it doesn’t keep in mind which server’s instance will process it. This responsibility is assigned to server’s loan balancers that after cathing the request decides which server’s instance should deal with it.
Circuit breaker
As the name suggests the pattern defines how to handle effieciently failed calls to another service. If we call the service several times and that’s ended with no response or errors, the next call will likely also fail. To prevent the case, the circuit break implementation will stop future calls. In case of long execution of request without result the circuit breaker can “kill” the call.
Fallback processing
Business logic of the client may require not to lose requests and process all of them with a certain result. How to handle a remote service call failure in that case? The pattern defines that rather than handle the problem with an exception it would be better to process the request in an alternative way or may be just queueing it for future processing.
Bulkheads
The pattern suggests to split resources into groups under the same service instance in a such way that proccessing of a request to resource A doesn’t block calls to resource B. The main purpose of the pattern to prevent taking an entire service down in case of faults in one part of it.
Out of the box solution: Netflix Hystrix.