Make your API more Resilient
Resiliency is the ability to recover from failures and continue to function. It isn’t about avoiding failures but accepting the fact that failures will happen and responding to them in a way that avoids downtime or data loss. The goal of resiliency is to return the application to a fully functioning state after a failure.
Let’s assume our backend system depends on another service to get another data this scenario is normal for us, no system can work alone, the customer requests to get some information let’s say about billing or payment or anything we can build our response object by calling another service A, B property from our system and can C get from another service or we can use the response from another service to build the main response this is good when all is work. code will look like this pseudocode
but we have a lot of issue
1. Response Time (Timeout):
- Let’s figure out exactly how long the other service takes to finish. The picture shows about 2 seconds, but we need to know if it could take more or less. Also, it’s important to think about what happens if it takes too long. Waiting a long time for a response isn’t good for our customers.
2. Service Downtime Plan (Circuit Breaker):
- What do we do if the other service is down for a long time? Do we keep sending requests every time a user asks for data? We need a plan for when things don’t work as expected.
3. Dealing with Service Problems (Retry):
- If the service is down, should we try sending the request again right away, or should we wait a bit? Figuring out what to do when the service has a short hiccup is important.
4. Sending the Right Message during Problems (Custom fallback):
- If the service is down, what kind of message should we send? Do we tell the user there’s a problem with a Bad Request or say there’s an Internal Server Error? Deciding on the best way to communicate issues is key.
First, when you see this line of code in your product you should ask yourself the 4 points I mentioned above and you should answer this question almost you should implement the 4 points based on your business. I always used Polly package to apply the four points. The first thing is
- Timeout you should specify the timeout for this request, you should receive a response in a certain amount of time, if the response exceeds the time cancel the request, by adding timeout police to HttpClient
2. Circuit Breaker is beneficial when the service is down. Calling it every time consumes a significant amount of time and resources unnecessarily. In instances when the service is down, there’s no need to wait or send requests. Instead, it’s more efficient to try again after a certain period only if the service is up and running. so we need to add circuit breaker policy to our HttpClient.
If three consecutive requests fail, the system refrains from calling the API, and the circuit breaker remains open for a duration of 10 minutes. After this period, a new request is sent. If the request continues to fail, the circuit breaker will reopen. However, if the API responds successfully, the circuit breaker will close.
3. Retry Implementing a retry policy is essential to address temporary failures in the service. There are instances where the API may experience temporary issues, and in such cases, it is prudent to incorporate a mechanism for retrying the API call.
Add retry exponential when the response is not found.
4. Custom fallback — in some cases a service’s client library provides a fallback method we can invoke, or in other cases, we can use locally available data on an API server (eg, a cookie or local cache) to generate a fallback response
Add Custom Fallback when HttpClient any Fail try to return anything else you can custom what you need. you can read more about Polly and how to using from Github.
