A retry repeats an operation after an earlier attempt fails or leaves its result uncertain. It helps an application recover from temporary failures instead of remaining unavailable. A retry is useful only when another attempt might succeed: a database that cannot be reached may recover, but an invalid request will remain invalid. section 16.2 section 16.2.1
Who makes the next attempt depends on how the components communicate:
- With a synchronous request, the sender implements retry logic. If an error arrives or no response arrives within a set time, it sends the request again. section 16.2.1
- With an asynchronous queue, a consumed message that is not acknowledged becomes available again after a timeout. Another consumer can then process it. section 16.2.1
Design the operation for repeated execution, not just the first attempt. An idempotent operation has the same outcome however many times it is applied. Otherwise, retrying a blog-post creation request can insert duplicate posts. One approach is to have the client generate a UUID and send it with the post: the backend inserts the record only if that primary key does not already exist. A duplicate-key response can also indicate that the insert has already succeeded; other database errors still need attention. section 16.2.2
Figure 16.5 Idempotent database insert: Creating a blog post entry in the database only if it doesn’t already exist
The diagram follows a blog-post insert that creates a database entry only when its key does not already exist. section 16.2.2
Retrying a multi-step post
Creating a blog post may also invalidate a cache and share a link to a social feed. A retry must account for these steps as well as the database insert; preventing duplicate records alone does not make the whole operation safe to repeat. section 16.2.2
Retries also help with concurrent updates. If DynamoDB rejects an update because another process changed the item's version, reread the item and try the change against its current version. This optimistic-locking approach can create substantial retry overhead when many processes write the same item concurrently. section 16.3.2
Do not retry a message forever when every attempt fails. For an SQS queue, configure a dead-letter queue to receive messages after a chosen number of unsuccessful attempts. A CloudWatch alarm can flag messages there for investigation; after fixing the problem, move them back to the original queue for processing. section 16.3.4
