Tidbits on Retries and Idempotency

Summary

• API calls should be retried if possible to avoid customer impact.
• However, retrying apis risks the possibly of duplicate operations if they are not idempotent.
• There are multiple ways of implementing idempotency, each with their own implications.
  • Implement Idempotency Key:
    • This involves adding a field to your api interface that represents the current request, let’s call it request id. If another request comes in from the same client with the same request id (idempotency key) then we assume it is a duplicate and not execute the api operation.
  • Hashing Requests:
    • You could hash all the request parameters for a client, store the the hash in the database, and then assume if another request comes in with the same hash then it is a duplicate request and not execute the api operation.
• After identifying a duplicate, you could choose to either:
  • Return a successful response with previous output
    • The api would return a successful response equivalent with what would have been received the first time.
    • This has the benefit that the retry operation will be mostly transparent to the caller (they don’t have to code an error path for retries).
  • Return some error response
    • The api would return an error code (ex: 409 Conflict) to represent the operation could not be executed.