Idempotency
berkansasmaz.com
Idempotency
1–10 of 69 posts
Re: Idempotency
#2Reading this article is completely safe even if you already understand idempotency.
Re: Idempotency
#3One of the things I think I did right in my career is working on payment and billing systems early on.
It does teach you how to build at least semi-reliable software because people tend to get really mad when you screw with their money. It also is a good introduction to regulation and compliance.
Idempotency was is one of the concepts you get taught on day one in that field (as kind of demonstrated by that being the example used by the author in the article).
Re: Idempotency
#4I know it's just an introduction so perhaps it shouldn't be taken too literally, but the sequence diagram of how to make an order idempotent feels like instructions on how to create race conditions.
You can't check for existence to guard against duplicate creation without either locking or another approach to making the Exists-or-Create step atomic.
If you were to put in the sequence as described, you'd have something which is idempotent most of the time, until it isn't, when API requests come in and get forwarded to the endpoint before the caching server can cache the first creation.
Re: Idempotency
#5Come here to learn more details and maybe find answers to my questions. Unfortunately, the article is very modest explaining how to work with idempotency.
Missing key answers like what about two requests in flight, how to store and query requests status reliably.
The article mention requests should be ACID, but the diagram has caching storage. Would redis/dynamodb work here?
Re: Idempotency
#6Idempotency is one mathematical concept that's pretty useful for software engineers to understand. Heck, might be more useful than BigO.
- Useful to know when you work with APIs (as the article outlines).
- Very useful when working with background jobs. You're not gonna have a good time if those aren't idempotent.
- Good to know for interviews. I was asked to explain idempotency a handful of times, weird as that is.
Re: Idempotency
#7I know it's just an introduction so perhaps it shouldn't be taken too literally, but the sequence diagram of how to make an order idempotent feels like instructions on how to create race conditions. You can't check for existence to guard against duplicate creation without either locking or another approach to making the Exists-or-Create step atomic. If you were to put in the sequence as described, you'd have somethin…
Presumably unique constraints could also solve for this, in a properly written transaction.
Re: Idempotency
#8[flagged]
Re: Idempotency
#9Reading this article is completely safe even if you already understand idempotency.
[deleted]
Re: Idempotency
#10I know it's just an introduction so perhaps it shouldn't be taken too literally, but the sequence diagram of how to make an order idempotent feels like instructions on how to create race conditions. You can't check for existence to guard against duplicate creation without either locking or another approach to making the Exists-or-Create step atomic. If you were to put in the sequence as described, you'd have somethin…
As I understand it, it's not checking for the existence of the resource but for the existence of the request. Assuming the requests are unique to a user/client and the user has a sequential conversation with the API server, the server would process the received requests in order and would reject the duplicate.
However, if the requests of the same key (duplicates) are sent to any of several API servers, you have a problem that must be resolved as you mentioned.
In the first case, if the API server dies, the client should establish a new connection and get new idempotency keys.