title: Retries in AWS SDK
body: <p>This <a href="https://docs.aws.amazon.com/general/latest/gr/api-retries.html" rel="nofollow noreferrer">doc</a> indicates that using the aws sdk gives you out-of-the-box retry functionality. </p>
  
  <p>Then this <a href="https://docs.aws.amazon.com/sdk-for-go/api/aws/#Config" rel="nofollow noreferrer">doc</a> states </p>
  
  <pre><code>// The maximum number of times that a request will be retried for failures.
  // Defaults to -1, which defers the max retry setting to the service
  // specific configuration.
  MaxRetries *int
  </code></pre>
  
  <p>which tells me that retry logic configuration happens at the service level. </p>
  
  <p>If this is the case, I would expect individual services to document their retry logic configuration. Not only is this not the case in actuality, several (actions of) services seem to imply that they don't provide retry logic, and, instead, discuss how this might be implemented at the application level. See for example <a href="https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Programming.Errors.html#Programming.Errors.BatchOperations" rel="nofollow noreferrer">dynamodb</a>:</p>
  
  <blockquote>
    <p>If DynamoDB returns any unprocessed items, you should retry the batch
    operation on those items. However, we strongly recommend that you use
    an exponential backoff algorithm. If you retry the batch operation
    immediately, the underlying read or write requests can still fail due
    to throttling on the individual tables. If you delay the batch
    operation using exponential backoff, the individual requests in the
    batch are much more likely to succeed.</p>
  </blockquote>
  
  <p>and <a href="https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/using-receiverequestattemptid-request-parameter.html" rel="nofollow noreferrer">sqs</a>: </p>
  
  <blockquote>
    <p>The receive request attempt ID is the token used for deduplication of
    ReceiveMessage calls.</p>
    
    <p>During a long-lasting network outage that causes connectivity issues
    between your SDK and Amazon SQS, it's a best practice to provide the
    receive request attempt ID and to retry with the same receive request
    attempt ID if the SDK operation fails.</p>
  </blockquote>
  
  <p>My question is how do I know when a service is handling the retry logic and when I have to implement it at the application level?</p>