An operation is idempotent when performing it multiple times has the same effective outcome as performing it once. This matters when an application retries work after a failure: the first attempt may have succeeded even if the caller did not receive a response. Without idempotency, retrying a blog-post request could create several identical database entries. section 16.2.2 section 16.2.1
Idempotency also helps with SQS message processing. SQS may deliver a message again if it is not deleted within its visibility timeout, or, rarely, if deletion does not remove every copy. A worker must therefore be prepared to process the same message more than once. In a URL-to-image workflow, uploading the result to the same S3 location replaces the existing image, leaving the intended result unchanged. section 14.2.6
For a retryable blog-post request:
- Have the client generate a UUID and send it with the post’s title and text. Use that UUID as the database primary key. section 16.2.2
- Insert the post only if its primary key is absent. Alternatively, attempt the insert and treat a duplicate-key error as successful completion; a different database error remains a failure. section 16.2.2
- Consider every subsequent action separately. The workflow also invalidates a cache and posts a link to a Twitter feed; making the database insert idempotent does not, by itself, establish the same property for the whole workflow. section 16.2.2
Retry when failure may be temporary, such as an unreachable database; retrying invalid request content will not make it valid. Some effects are harder to make idempotent: sending an email on every delivery sends multiple emails. Check whether at-least-once processing fits the application’s requirements rather than assuming retries are harmless. section 16.2.1 section 14.2.6
