# Luca Palmieri - An in-Depth Introduction to Idempotency (Highlights)  ## Metadata **Cover**:: https://readwise-assets.s3.amazonaws.com/static/images/article1.be68295a7e40.png **Source**:: #from/readwise **Zettel**:: #zettel/fleeting **Status**:: #x **Authors**:: [[Luca Palmieri]] **Full Title**:: An in-Depth Introduction to Idempotency **Category**:: #articles #readwise/articles **Category Icon**:: 📰 **URL**:: [www.lpalmieri.com](https://www.lpalmieri.com/posts/idempotency/) **Host**:: [[www.lpalmieri.com]] **Highlighted**:: [[2022-03-25]] **Created**:: [[2022-09-26]] ## Highlights - Retry-safety has a dramatic impact on the ergonomics of an API. It is substantially easier to write a reliable API client if you can safely retry when something goes wrong. - The caller generates a unique identifier, the idempotency key, for every state-altering operation they want to perform. ### 6. Implementation Strategies #### 6.1. Stateful Idempotency: Save And Replay - When a retry comes in, we look for a match in the store against its idempotency key, fetch the saved HTTP response and return it to the caller. #### 6.2. Stateless Idempotency: Deterministic Key Generation - When a retry comes in, we execute the same processing logic - this leads to the same sequence of HTTP calls to Postmark, using exactly the same idempotency keys. Assuming their idempotency implementation is sound, no new email is going to be dispatched. #### 6.3. Time Is a Tricky Beast - This is a symptom of a deeper discrepancy - the elapsed time between the initial request and the following retry affects the processing outcome when following the stateless approach.