Resiliency Patterns

Core Resiliency Patterns

1. Retry Pattern

• Uses a "retryForever" policy with constant backoff
• Configured with 5-second intervals between retries
• Set to unlimited retries (maxRetries: -1) to handle transient failures
• Applied automatically when component operations fail

2. Circuit Breaker Pattern

• Implements a "simpleCB" circuit breaker with three states: closed, open, and half-open
• Trip condition: Opens after 5 consecutive failures
• Timeout: Remains open for 5 seconds before transitioning to half-open
• Test requests: Allows 1 request in half-open state to test if service has recovered
• Recovery: Closes circuit if test request succeeds, reopens if it fails

Configuration Structure

The resiliency patterns are defined in a YAML specification that includes:

• Policies section: Defines retry and circuit breaker behaviors
• Targets section: Specifies which components (like the statestore) the policies apply to
• Scoping: Applied to specific Dapr applications through the scopes field

Fault Handling Workflow

1. Normal operation: Application continuously saves and retrieves state via Dapr APIs
2. Fault introduction: When the backing service (Redis) becomes unavailable, requests begin failing
3. Retry activation: Failed requests trigger the retry policy with constant 5-second intervals
4. Circuit breaker engagement: After 5 consecutive retry failures, the circuit breaker opens and halts requests
5. Recovery testing: Circuit breaker periodically switches to half-open to test service availability
6. Automatic recovery: Once the backing service is restored, the application seamlessly resumes normal operation

This demonstrates how Dapr's resiliency features provide automatic fault tolerance for service-to-component interactions without requiring application code changes.