The documentation you are viewing is for Dapr v1.13 which is an older version of Dapr. For up-to-date documentation, see the latest version.
Targets
Targets
Named policies are applied to targets. Dapr supports three target types that apply all Dapr building block APIs:
apps
components
actors
Apps
With the apps
target, you can apply retry
, timeout
, and circuitBreaker
policies to service invocation calls between Dapr apps. Under targets/apps
, policies are applied to each target service’s app-id
. The policies are invoked when a failure occurs in communication between sidecars, as shown in the diagram below.
Dapr provides built-in service invocation retries, so any applied
retry
policies are additional.
![Diagram showing service invocation resiliency](/images/resiliency_svc_invocation.png)
Example of policies to a target app with the app-id
“appB”:
specs:
targets:
apps:
appB: # app-id of the target service
timeout: general
retry: general
circuitBreaker: general
Components
With the components
target, you can apply retry
, timeout
and circuitBreaker
policies to component operations.
Policies can be applied for outbound
operations (calls to the Dapr sidecar) and/or inbound
(the sidecar calling your app).
Outbound
outbound
operations are calls from the sidecar to a component, such as:
- Persisting or retrieving state.
- Publishing a message on a PubSub component.
- Invoking an output binding.
Some components may have built-in retry capabilities and are configured on a per-component basis.
![Diagram showing service invocation resiliency](/images/resiliency_outbound.png)
spec:
targets:
components:
myStateStore:
outbound:
retry: retryForever
circuitBreaker: simpleCB
Inbound
inbound
operations are calls from the sidecar to your application, such as:
- PubSub subscriptions when delivering a message.
- Input bindings.
Some components may have built-in retry capabilities and are configured on a per-component basis.
![Diagram showing service invocation resiliency](/images/resiliency_inbound.png)
spec:
targets:
components:
myInputBinding:
inbound:
timeout: general
retry: general
circuitBreaker: general
PubSub
In a PubSub target/component
, you can specify both inbound
and outbound
operations.
![Diagram showing service invocation resiliency](/images/resiliency_pubsub.png)
spec:
targets:
components:
myPubsub:
outbound:
retry: pubsubRetry
circuitBreaker: pubsubCB
inbound: # inbound only applies to delivery from sidecar to app
timeout: general
retry: general
circuitBreaker: general
Actors
With the actors
target, you can apply retry
, timeout
, and circuitBreaker
policies to actor operations.
When using a circuitBreaker
policy for the actors
target, you can specify how circuit breaking state should be scoped by using circuitBreakerScope
:
id
: an individual actor IDtype
: all actors of a given actor typeboth
: both of the above
You can also specify a cache size for the number of circuit breakers to keep in memory with the circuitBreakerCacheSize
property, providing an integer value, e.g. 5000
.
Example
spec:
targets:
actors:
myActorType:
timeout: general
retry: general
circuitBreaker: general
circuitBreakerScope: both
circuitBreakerCacheSize: 5000
Next steps
Try out one of the Resiliency quickstarts:
Feedback
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.