The documentation you are viewing is for Dapr v1.8 which is an older version of Dapr. For up-to-date documentation, see the latest version.

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”:

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.
  • 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
spec:
  targets:
    components:
      myStateStore:
        outbound:
          retry: retryForever
          circuitBreaker: simpleCB
Inbound

inbound operations are calls from the sidecar to your application, such as:

  • 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
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
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, you can specify whether circuit breaking state should be scoped to:

  • An individual actor ID.
  • All actors across the actor type.
  • Both.

Specify circuitBreakerScope with values id, type, or both.

You can specify a cache size for the number of circuit breakers to keep in memory. Do this by specifying circuitBreakerCacheSize and providing an integer value, e.g. 5000.

Example

spec:
  targets:
    actors:
      myActorType:
        timeout: general
        retry: general
        circuitBreaker: general
        circuitBreakerScope: both
        circuitBreakerCacheSize: 5000

Last modified April 6, 2022: PR feedback (3f5b4887)