Dev.to

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 Normal operation: Application continuously saves and retrieves state via Dapr APIs Fault introduction: When the backing service (Redis) becomes unavailable, requests begin failing Retry activation: Failed requests trigger the retry policy with constant 5-second intervals Circuit breaker engagement: After 5 consecutive retry failures, the circuit breaker opens and halts requests Recovery testing: Circuit breaker periodically switches to half-open to test service availability 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.

Jun 24, 2025 - 08:20

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

Normal operation: Application continuously saves and retrieves state via Dapr APIs
Fault introduction: When the backing service (Redis) becomes unavailable, requests begin failing
Retry activation: Failed requests trigger the retry policy with constant 5-second intervals
Circuit breaker engagement: After 5 consecutive retry failures, the circuit breaker opens and halts requests
Recovery testing: Circuit breaker periodically switches to half-open to test service availability
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.