Targets

Apply resiliency policies to apps, components and actors

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

Example of policies to a target app with the app-id “appB”:

  1. specs:
  2.   targets:
  3.     apps:
  4.       appB: # app-id of the target service
  5.         timeout: general
  6.         retry: general
  7.         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

  1. spec:
  2.   targets:
  3.     components:
  4.       myStateStore:
  5.         outbound:
  6.           retry: retryForever
  7.           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

  1. spec:
  2.   targets:
  3.     components:
  4.       myInputBinding:
  5.         inbound: 
  6.           timeout: general
  7.           retry: general
  8.           circuitBreaker: general
PubSub

In a PubSub target/component, you can specify both inbound and outbound operations.

Diagram showing service invocation resiliency

  1. spec:
  2.   targets:
  3.     components:
  4.       myPubsub:
  5.         outbound:
  6.           retry: pubsubRetry
  7.           circuitBreaker: pubsubCB
  8.         inbound: # inbound only applies to delivery from sidecar to app
  9.           timeout: general
  10.           retry: general
  11.           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 ID
  • type: all actors of a given actor type
  • both: 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

  1. spec:
  2.   targets:
  3.     actors:
  4.       myActorType:
  5.         timeout: general
  6.         retry: general
  7.         circuitBreaker: general
  8.         circuitBreakerScope: both
  9.         circuitBreakerCacheSize: 5000

Next steps

Try out one of the Resiliency quickstarts:

Last modified June 19, 2023: Merge pull request #3565 from dapr/aacrawfi/skip-secrets-close (b1763bf)