Description
With the introduction of Dap resiliency policies https://docs.dapr.io/operations/resiliency/ there needs to be guidance on a per component basis on how to apply these policies. This is best included as an output table or two tables in the case of pub/sub, one for the output and one for the input, for subscription retry
Template
Resiliency outbound policy | Recommend value |
---|---|
Timeout | no recommendation yet, please contribute a recommendation |
Retry | no recommendation yet, please contribute a recommendation |
Circuit Breaker | no recommendation yet, please contribute a recommendation |
Resiliency inbound policy | Recommend value |
---|---|
Timeout | no recommendation yet, please contribute a recommendation |
Retry | no recommendation yet, please contribute a recommendation |
Circuit Breaker | no recommendation yet, please contribute a recommendation |
Example
Resiliency outbound policy | Recommend value |
---|---|
Timeout | 3 seconds |
Retry | policy: exponential, maxInterval: 15s, maxRetries: -1 |
Circuit Breaker | maxRequests: 1, timeout: 30s, trip: consecutiveFailures >= 5 |
All component files would be updated to include template
The first component to have actually values added would be Azure CosmosDB, Redis and Mongo. If you are using one of these components currently we would like to hear about suggested values you have set.
It should also be noted in the template section that some components have a "component-native retries" which are often built into either the SDK used by the component or into the service that a component interacts with. In most cases where a component has "component-native retries" these should be considered first in preference to the Dapr resiliency policy.