PB-2395: add a page about retry strategy. - #minor - #182
Conversation
github-actions
Bot
changed the title
e605f24 to
82ddb26
Compare
86297b8 to
ca26c07
Compare
Users retry strategy is often suboptimal and in some cases may exacerbate outages. Implementing a correct retry strategy is non-trivial and we cannot expect all users to do it well. However even imperfect efforts are strictly better for us than the status quo. We have had at least one user with a simplistic retry strategy that prompted them to open a ticket. This change adds a page that explains the retry strategy we wish our users to implement.
ca26c07 to
dc7e2b4
Compare
asteiner-swisstopo
left a comment
asteiner-swisstopo
left a comment
There was a problem hiding this comment.
I like it 👍 Just some minor formatting things and a section I would consider to remove.
| items: [{ text: 'Overview', link: '/get-started/overview' }], | ||
| items: [ | ||
| { text: 'Overview', link: '/get-started/overview' }, | ||
| { text: 'Retrying failed requests', link: '/get-started/retry' }, |
There was a problem hiding this comment.
All other pages use title case, I suggest we do that here too.
|
|
||
| 1. Send a request. | ||
|
|
||
| 2. Upon retryable failure, wait 1 + `jitter` seconds before retrying. |
There was a problem hiding this comment.
The formatting of the numbered list looks odd, there is no identation. Maybe because there is an empty line between each point?
| cancel the request. You should pick a value appropriate to your use case. One | ||
| way to think about it is "how long to keep trying until we need to involve a | ||
| human?". For example, if you are fetching a tile to display in an interactive | ||
| application, there is probably no point retrying for 3 minutes as the user will |
There was a problem hiding this comment.
Nitpick but I think small numbers are usually written out 🙃
| application, there is probably no point retrying for 3 minutes as the user will | |
| application, there is probably no point retrying for three minutes as the user will |
| ## Third party libraries | ||
|
|
||
| You are welcome to use a third party library to implement your retry strategy | ||
| but it is your responsibility to verify it actually implements a truncated | ||
| exponential backoff algorithm with jitter with reasonable parametres under your | ||
| control. |
There was a problem hiding this comment.
Personally, I find this sound a bit patronizing. I would leave it away, it adds nothing add isn't clear already ("you are responsible!").
If you want to keep it, I would at least avoid the repeating the "it is your responsibility" that is just above.
| You can also find further information in the following references: | ||
|
|
||
| - [Wikipedia: Exponential Backoff](https://en.wikipedia.org/wiki/Exponential_backoff#Truncated_exponential_backoff) | ||
| - [Google SRE Book: Adressing Cascading Failures: Retries](https://sre.google/sre-book/addressing-cascading-failures/#retires) |
There was a problem hiding this comment.
Typo? Odd that it still works...
| - [Google SRE Book: Adressing Cascading Failures: Retries](https://sre.google/sre-book/addressing-cascading-failures/#retires) | |
| - [Google SRE Book: Adressing Cascading Failures: Retries](https://sre.google/sre-book/addressing-cascading-failures/#retries) |
There was a problem hiding this comment.
Yeah, they messed up. I'll see if I can figure out how to open a bug^Wtypo report against them.
There was a problem hiding this comment.
Report sent by e-mail to Betsy Beyer.
There was a problem hiding this comment.
I also reported the issue on the editor's website: https://www.oreilly.com/catalog/errataunconfirmed.csp?isbn=0636920041528
| You can also find further information in the following references: | ||
|
|
||
| - [Wikipedia: Exponential Backoff](https://en.wikipedia.org/wiki/Exponential_backoff#Truncated_exponential_backoff) | ||
| - [Google SRE Book: Adressing Cascading Failures: Retries](https://sre.google/sre-book/addressing-cascading-failures/#retires) |
There was a problem hiding this comment.
Typo:
| - [Google SRE Book: Adressing Cascading Failures: Retries](https://sre.google/sre-book/addressing-cascading-failures/#retires) | |
| - [Google SRE Book: Addressing Cascading Failures: Retries](https://sre.google/sre-book/addressing-cascading-failures/#retires) |
|
Following up on @asteiner-swisstopo comments in #183 |
3 participants
Users retry strategy is often suboptimal and in some cases may exacerbate outages. Implementing a correct retry strategy is non-trivial and we cannot expect all users to do it well. However even imperfect efforts are strictly better for us than the status quo.
We have had at least one user with a simplistic retry strategy that prompted them to open a ticket.
This change adds a page that explains the retry strategy we wish our users to implement.
Direct test link to the new page
Test link