You have an application that makes HTTP requests to Cloud Storage. Occasionally the requests fail with HTTP status codes of 5xx and 429. How should you handle these types of errors?
A.
Use gRPC instead of HTTP for better performance.
B.
Implement retry logic using a truncated exponential backoff strategy.
C.
Make sure the Cloud Storage bucket is multi-regional for geo-redundancy.
D.
Monitor https://status.cloud.google.com/feed.atom and only make requests if Cloud Storage is not reporting an incident.
Answer is B
You should use exponential backoff to retry your requests when receiving errors with 5xx or 429 response codes from Cloud Storage.
https://cloud.google.com/storage/docs/request-rate
HTTP 408, 429, and 5xx response codes.
Exponential backoff algorithm
For requests that meet both the response and idempotency criteria, you should generally use truncated exponential backoff.
Truncated exponential backoff is a standard error handling strategy for network applications in which a client periodically retries a failed request with increasing delays between requests.
An exponential backoff algorithm retries requests exponentially, increasing the waiting time between retries up to a maximum backoff time. See the following workflow example to learn how exponential backoff works:
You make a request to Cloud Storage.
If the request fails, wait 1 + random_number_milliseconds seconds and retry the request.
If the request fails, wait 2 + random_number_milliseconds seconds and retry the request.
If the request fails, wait 4 + random_number_milliseconds seconds and retry the request.
And so on, up to a maximum_backoff time.
Continue waiting and retrying up to a maximum amount of time (deadline), but do not increase the maximum_backoff wait period between retries
. Implement retry logic using a truncated exponential backoff strategy.
HTTP status codes of 5xx and 429 typically indicate that there is a temporary issue with the service or that the rate of requests is too high. To handle these types of errors, it is generally recommended to implement retry logic in your application using a truncated exponential backoff strategy.
Truncated exponential backoff involves retrying the request after an initial delay, and then increasing the delay exponentially for each subsequent retry up to a maximum delay. This approach helps to reduce the number of failed requests and can improve the reliability of your application.
Option A, using gRPC instead of HTTP for better performance, is not directly related to handling HTTP status codes of 5xx and 429. gRPC is a high-performance RPC framework that can be used in place of HTTP, but it is not a solution for handling errors.
Option C, making sure the Cloud Storage bucket is multi-regional for geo-redundancy, may help improve the reliability of the service, but it is not a solution for handling errors.
Option D, monitoring https://status.cloud.google.com/feed.atom and only making requests if Cloud Storage is not reporting an incident, is not a practical solution for handling errors. This approach would require constantly monitoring the status page and could result in significant delays in processing requests. Instead, it is generally recommended to implement retry logic in your application to handle errors.
B – Implement retry logic using a truncated exponential backoff strategy.
Per HTTP status and error codes for JSON the status codes are:
2xx – successful requests;
4xx, 5xx – failed requests;
3xx – requests that require redirect.
https://cloud.google.com/storage/docs/json_api/v1/status-codes
429 – Too many requests: your app tries to use more that its limit, additional requests will fail. Decrease your client’s requests and/or use truncated exponential backoff (used for all requests with 5xx and 429 errors).
https://cloud.google.com/storage/docs/retry-strategy
As per google, if you run into any issue as increase latency or erroe rate ,pause your ramp up this give cloudstorage more time to scale your bucket . Best is backoff when 5xx ,429,408 response code
A voting comment increases the vote count for the chosen answer by one.
Upvoting a comment with a selected answer will also increase the vote count towards that answer by one.
So if you see a comment that you already agree with, you can upvote it instead of posting a new comment.
bigob4ek
Highly Voted 3 years, 11 months agonitinz
2 years, 7 months agoAzureDP900
1 year agoSbgani
Highly Voted 1 year, 1 month agoJonathanSJ
Most Recent 3 months, 4 weeks agoomermahgoub
10 months, 1 week agoomermahgoub
10 months, 1 week agomegumin
11 months, 3 weeks agoSbgani
1 year, 1 month agoDrishaS4
1 year, 2 months agoharoldbenites
1 year, 10 months agovincy2202
1 year, 11 months agonqthien041292
1 year, 11 months agojoe2211
1 year, 11 months agoMaxNRG
1 year, 12 months agovictory108
2 years, 5 months agovictory108
2 years, 5 months agoun
2 years, 5 months agoAusias18
2 years, 6 months agoCloudGenious
2 years, 8 months agobnlcnd
2 years, 9 months ago