|
| 1 | +# Adaptive Retry Strategy Concepts |
| 2 | + |
| 3 | +## Overview |
| 4 | + |
| 5 | +AWS Java SDK's `AdaptiveRetryStrategy` is a specialized retry strategy designed for use cases with high resource constraints. It includes all features of the standard retry strategy plus a client-side rate limiter that measures throttled vs non-throttled requests to minimize throttling errors. |
| 6 | + |
| 7 | +> **⚠️ Important**: AdaptiveRetryStrategy assumes the client works against a single resource (e.g., one DynamoDB table or one S3 bucket). AWS recommends StandardRetryStrategy for most use cases. |
| 8 | +
|
| 9 | +## Standard Retry vs Adaptive Retry |
| 10 | + |
| 11 | +### Standard Retry Policies |
| 12 | + |
| 13 | +Traditional retry policies use fixed algorithms with predetermined backoff strategies: |
| 14 | + |
| 15 | +- **Fixed Backoff**: Same delay between all retry attempts |
| 16 | +- **Exponential Backoff**: Exponentially increasing delays (2^attempt * base_delay) |
| 17 | +- **Linear Backoff**: Linearly increasing delays (attempt * base_delay) |
| 18 | + |
| 19 | +**Limitations:** |
| 20 | +- Cannot adapt to real-time service conditions |
| 21 | +- May be too aggressive during service degradation |
| 22 | +- May be too conservative during normal operations |
| 23 | +- Fixed retry counts regardless of error type |
| 24 | + |
| 25 | +### Adaptive Retry Strategy |
| 26 | + |
| 27 | +Adaptive retry includes all features of the standard strategy and adds: |
| 28 | + |
| 29 | +- **Client-Side Rate Limiter**: Measures the rate of throttled requests compared to non-throttled requests |
| 30 | +- **Dynamic Request Rate**: Slows down requests to stay within safe bandwidth |
| 31 | +- **Load-Based Adaptation**: Uses dynamic backoff delay based on current load against downstream resources |
| 32 | +- **Circuit Breaking**: May prevent second attempts in outage scenarios to protect downstream services |
| 33 | + |
| 34 | +**Benefits:** |
| 35 | +- **Throttling Prevention**: Attempts to cause zero throttling errors through rate limiting |
| 36 | +- **Resource Protection**: Protects downstream services from retry storms |
| 37 | +- **Load Adaptation**: Adjusts to real-time service conditions and traffic patterns |
| 38 | +- **Bandwidth Optimization**: Adjusts request rate to minimize throttling |
| 39 | + |
| 40 | +## How Adaptive Retry Works |
| 41 | + |
| 42 | +### 1. Client-Side Rate Limiting |
| 43 | +- Implements a token bucket mechanism to control request rates |
| 44 | +- Measures throttled vs non-throttled request ratios |
| 45 | +- Reduces request rate when throttling is detected |
| 46 | +- May delay initial attempts in high-traffic scenarios |
| 47 | + |
| 48 | +### 2. Dynamic Backoff Strategy |
| 49 | +- Uses dynamic backoff delay based on current load against downstream resources |
| 50 | +- Adapts in real-time to changing service conditions and traffic patterns |
| 51 | +- Different from standard exponential backoff - timing adjusts based on service load |
| 52 | + |
| 53 | +### 3. Circuit Breaking Protection |
| 54 | +- Performs circuit breaking when high downstream failures are detected |
| 55 | +- May prevent second attempts during outage scenarios |
| 56 | +- Designed to protect downstream services from retry storms |
| 57 | +- First attempt is always executed, only retries may be disabled |
| 58 | + |
| 59 | +## When to Use Adaptive Retry |
| 60 | + |
| 61 | +### Appropriate Use Cases |
| 62 | +- **High resource constraint environments** where minimizing throttling is critical |
| 63 | +- **Single-resource applications** (one DynamoDB table, one S3 bucket per client) |
| 64 | +- **Applications experiencing frequent throttling** with standard retry strategies |
| 65 | +- **Environments where all clients use adaptive retry** against the same resource |
| 66 | + |
| 67 | +### Use Standard Retry Instead When |
| 68 | +- **Multi-resource clients** (one client accessing multiple tables/buckets) |
| 69 | +- **General use cases** - AWS recommends StandardRetryStrategy for most applications |
| 70 | +- **Mixed client environments** where not all clients use adaptive retry |
| 71 | +- **Applications requiring predictable retry timing** |
| 72 | + |
| 73 | +### Critical Limitations |
| 74 | +⚠️ **Single Resource Assumption**: If you use a single client for multiple resources, throttling or outages with one resource will cause increased latency and failures for all other resources accessed by that client. |
| 75 | + |
| 76 | +## Key Concepts |
| 77 | + |
| 78 | +### Client-Side Rate Limiting |
| 79 | +Adaptive retry includes built-in client-side rate limiting to prevent overwhelming services during degradation. |
| 80 | + |
| 81 | +### Token Bucket Mechanism |
| 82 | +Each client maintains a token bucket that provides a mechanism to stop retries when a large percentage of requests are failing and retries are unsuccessful. |
| 83 | + |
| 84 | +### Rate Measurement |
| 85 | +The strategy measures the rate of throttled requests compared to non-throttled requests to determine when to slow down request rates. |
| 86 | + |
| 87 | +### Error Classification |
| 88 | +Different retry strategies for different error types: |
| 89 | +- **Throttling errors**: Aggressive backoff with rate limiting |
| 90 | +- **Server errors**: Standard exponential backoff |
| 91 | +- **Client errors**: Minimal or no retries |
| 92 | + |
| 93 | +## Performance Implications |
| 94 | + |
| 95 | +### Latency |
| 96 | +- **Improved**: Enhanced recovery from transient issues |
| 97 | +- **Adaptive**: Longer delays during service degradation (by design) |
| 98 | + |
| 99 | +### Throughput |
| 100 | +- **Higher**: Better success rates through intelligent retry timing |
| 101 | +- **Stable**: Maintains throughput during service stress |
| 102 | + |
| 103 | +### Resource Usage |
| 104 | +- **Optimized**: Reduces unnecessary retry attempts |
| 105 | +- **Efficient**: Better CPU and network utilization |
| 106 | + |
| 107 | +## Testing and Validation |
| 108 | + |
| 109 | +### Compilation Testing |
| 110 | +Always test that your AdaptiveRetryStrategy configuration compiles correctly: |
| 111 | + |
| 112 | +```java |
| 113 | +@Test |
| 114 | +public void testAdaptiveRetryStrategyCompilation() { |
| 115 | + // Test basic configuration |
| 116 | + AdaptiveRetryStrategy strategy = AdaptiveRetryStrategy.builder() |
| 117 | + .maxAttempts(3) |
| 118 | + .build(); |
| 119 | + |
| 120 | + DynamoDbClient client = DynamoDbClient.builder() |
| 121 | + .overrideConfiguration(ClientOverrideConfiguration.builder() |
| 122 | + .retryStrategy(strategy) |
| 123 | + .build()) |
| 124 | + .build(); |
| 125 | + |
| 126 | + assertNotNull(client); |
| 127 | + client.close(); |
| 128 | +} |
| 129 | + |
| 130 | +@Test |
| 131 | +public void testRetryModeConfiguration() { |
| 132 | + // Test RetryMode approach |
| 133 | + DynamoDbClient client = DynamoDbClient.builder() |
| 134 | + .overrideConfiguration(ClientOverrideConfiguration.builder() |
| 135 | + .retryStrategy(software.amazon.awssdk.core.retry.RetryMode.ADAPTIVE) |
| 136 | + .build()) |
| 137 | + .build(); |
| 138 | + |
| 139 | + assertNotNull(client); |
| 140 | + client.close(); |
| 141 | +} |
| 142 | +``` |
| 143 | + |
| 144 | +### Runtime Validation |
| 145 | +Monitor retry behavior in your application logs to ensure the adaptive strategy is working as expected: |
| 146 | + |
| 147 | +- Watch for adaptive backoff patterns |
| 148 | +- Monitor throttling error rates |
| 149 | +- Observe request rate adjustments during load spikes |
| 150 | + |
| 151 | +## Implementation Details |
| 152 | + |
| 153 | +### Correct API Usage in AWS SDK v2 |
| 154 | + |
| 155 | +When implementing AdaptiveRetryStrategy, use the correct AWS SDK v2 API: |
| 156 | + |
| 157 | +```java |
| 158 | +// CORRECT - Basic AdaptiveRetryStrategy configuration |
| 159 | +AdaptiveRetryStrategy adaptiveRetryStrategy = AdaptiveRetryStrategy.builder() |
| 160 | + .maxAttempts(3) |
| 161 | + .backoffStrategy(BackoffStrategy.exponentialDelay( |
| 162 | + Duration.ofMillis(100), // base delay |
| 163 | + Duration.ofSeconds(20) // max delay |
| 164 | + )) |
| 165 | + .throttlingBackoffStrategy(BackoffStrategy.exponentialDelay( |
| 166 | + Duration.ofSeconds(1), // base delay for throttling |
| 167 | + Duration.ofSeconds(20) // max delay for throttling |
| 168 | + )) |
| 169 | + // Note: circuitBreakerEnabled() method doesn't exist - circuit breaking is built-in |
| 170 | + .build(); |
| 171 | + |
| 172 | +DynamoDbClient client = DynamoDbClient.builder() |
| 173 | + .overrideConfiguration(ClientOverrideConfiguration.builder() |
| 174 | + .retryStrategy(adaptiveRetryStrategy) // Use retryStrategy(), not retryPolicy() |
| 175 | + .build()) |
| 176 | + .build(); |
| 177 | +``` |
| 178 | + |
| 179 | +### Simplest Configuration Approach |
| 180 | + |
| 181 | +For basic adaptive retry behavior, use RetryMode: |
| 182 | + |
| 183 | +```java |
| 184 | +// CORRECT - Simplest adaptive retry configuration |
| 185 | +DynamoDbClient client = DynamoDbClient.builder() |
| 186 | + .overrideConfiguration(ClientOverrideConfiguration.builder() |
| 187 | + .retryStrategy(software.amazon.awssdk.core.retry.RetryMode.ADAPTIVE) |
| 188 | + .build()) |
| 189 | + .build(); |
| 190 | +``` |
| 191 | + |
| 192 | +### Key API Differences from Standard Retry |
| 193 | + |
| 194 | +- **Package**: `software.amazon.awssdk.retries.AdaptiveRetryStrategy` (not `core.retry`) |
| 195 | +- **Builder**: `AdaptiveRetryStrategy.builder()` (not `RetryPolicy.builder()`) |
| 196 | +- **Configuration**: `.retryStrategy()` (not `.retryPolicy()`) |
| 197 | +- **Circuit Breaking**: Built-in (no `.circuitBreakerEnabled()` method) |
| 198 | + |
| 199 | +## Next Steps |
| 200 | + |
| 201 | +Now that you understand the concepts, proceed to: |
| 202 | +1. [Migration Guide](migration-guide.md) - Convert existing retry policies with correct API usage |
| 203 | +2. [Configuration Reference](configuration-reference.md) - Detailed parameter documentation |
| 204 | +3. [Examples](../examples/) - Working, tested code implementations |
| 205 | + |
| 206 | +## Sources and References |
| 207 | + |
| 208 | +This conceptual guide is based on official AWS SDK for Java 2.x documentation: |
| 209 | + |
| 210 | +### Primary Sources |
| 211 | + |
| 212 | +1. **AWS SDK for Java 2.x Developer Guide - Configure retry behavior** |
| 213 | + *AWS Documentation* |
| 214 | + https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/retry-strategy.html |
| 215 | + Retrieved: August 18, 2025 |
| 216 | + |
| 217 | +2. **AWS SDK for Java 2.x API Reference - AdaptiveRetryStrategy** |
| 218 | + *AWS SDK API Documentation* |
| 219 | + https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/retries/AdaptiveRetryStrategy.html |
| 220 | + Retrieved: August 18, 2025 |
| 221 | + |
| 222 | +### Key Technical Details |
| 223 | + |
| 224 | +- **Retry Strategy Introduction**: Retry strategies were introduced in AWS SDK for Java 2.x version 2.26.0 as part of the AWS-wide effort to unify interfaces and behavior¹ |
| 225 | +- **Adaptive Strategy Purpose**: Designed specifically for "use cases with a high level of resource constraints"¹ |
| 226 | +- **Rate Limiting**: "Includes all the features of the standard strategy and adds a client-side rate limiter that measures the rate of throttled requests compared to non-throttled requests"¹ |
| 227 | +- **Single Resource Assumption**: "The adaptive retry strategy assumes that the client works against a single resource (for example, one DynamoDB table or one Amazon S3 bucket)"¹ |
| 228 | +- **AWS Recommendation**: StandardRetryStrategy is "the recommended RetryStrategy implementation for normal use cases" and "generally useful across all retry use cases" unlike AdaptiveRetryStrategy¹ |
| 229 | + |
| 230 | +--- |
| 231 | +**Citations:** |
| 232 | +1. AWS SDK for Java 2.x Developer Guide. "Configure retry behavior in the AWS SDK for Java 2.x." Amazon Web Services. https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/retry-strategy.html |
0 commit comments