61–70 of 244 posts
I think this article (and the author's previous articles on their blog) is quite clearly AI written. It has such a frustratingly punctuated cadence and really does not serve the reader anything valuable.
Not well organized, but not zero value.
I think this article (and the author's previous articles on their blog) is quite clearly AI written. It has such a frustratingly punctuated cadence and really does not serve the reader anything valuable.
If you like the article, upvote. If you don’t, don’t.
The point of idempotency is safe retries. Systems are completely fallible, all the way down to the network cables. The user wants something + the system might fail = the user must be able to try again. If the system does not try again, but instead parrots the text of the previous failure, why bother? You didn't build reliability into the system, you built a deliberately stale cache.
That's why you need to separate work from actual input. It's not about trying again but about making sure you get consistent state. Imagine request for payment. You made one and timeouted. Why did it timeout? Your network or payment service error? You don't know, so you can't decide between retry and not retry. Thus practice is: make request - ack request with status request id (idempotent, same request gives same st…
I'm well aware that the first order went through, even though the dumb system fumbled the translation of the success message and gave me a 500 back.
I do retry because I wanted the outcome. I'm not giving it a new key (firstly because I'm a user clicking a form, not choosing UUIDs for my shopping cart) but more importantly, if I did supply a second key, it's now my fault for ordering two copies.
I really hate the POST verb for RESTish APIs because it cannot be idempotent without implementing an idempotency layer. Other verbs are naturally idempotent. Has anyone tried foregoing POST routes entirely? Theoretically you can let the client generate an ID and have it request a PUT route to create new entities. This would give you a tiny amount of extra complexity on the client, but make the server simpler as a tra…
In what sense is GET naturally idempotent? The GET/POST split is the defence (even it's only advisory). GET-only means every time you hit the back button during an order flow, you might double-order.
One thing that's confusing, here, is that idempotency only applies for the same request, but the article implies that idempotency is about whether the request contains a specific "idempotency key".
Don't do that, and this problem evaporates.
This seems to assume retrying a command should result in the same response, but I am not sure I agree. Idempotency is about state, not communication. Send the same payment twice and one of them should respond "payment already exists".
I don’t know if we’re reading the same article? The linked one states very plainly: ”Idempotency is about the effect An operation is idempotent if applying it once or many times has the same intended effect.”
What's being asked for here is eventual consistency. If you make the same request twice, the system must settle into a the same state as if it was done only once. That's the realm of conflict-free replicated data types, which the article is trying to re-invent.
x = 1
x = x + 1
Idempotency is easy if you don't use mutable state in your middleware. Auth, logging, and atomicity are all isolated concerns that should not affect the domain specific user contract with your API. How you handle unique keys is going to vary by domain and tolerance-- and its probably not going to be the same in every table. It's important to design a database schema that can work independently of your middleware laye…
So idempotency is easy if your service does not do anything useful?
(Though I do disagree with the original premise too. Putting on a 'stateless' boxing glove won't mean there's no difference between punching a guy once or twice)
A couple of years ago, we experienced a silent data corruption incident in our checkout process due to this specific edge case. A user would generate the idempotency key by loading the front-end application, adding item(s) to their cart, submitting their order but timing out. The user would then navigate back to the front-end application and add another item and submit the order again. Since the user is submitting an…
The idempotency key should have been viewed as the untrustworthy hint it really is. Then you can decide whether an untrustworthy hint is what you really need. At that point I'd hope someone on the team says "This is ordering - I think we need something trustworthy"
> Consequently, the lesson we take away from the aforementioned incident is idempotency keys are really composite keys (Client_Provided_Key + Hash(Request_Payload)).
Did the postmortem result in any other (wider) changes/actions, out of curiosity?
No idea if this was anything like what happened your case, and probably going off on a tangent, but I've seen so many cases where teams are split into backend and frontend, and they stop thinking about the product as a single distributed system (or, it exacerbates that lack of that thinking from before). Frontend often suggest "Oh we can just create an idempotency key" and any concerns from backend are dismissed. If they implement it incorrectly, backend are on the wrong 'team' to provide input.
A couple of years ago, we experienced a silent data corruption incident in our checkout process due to this specific edge case. A user would generate the idempotency key by loading the front-end application, adding item(s) to their cart, submitting their order but timing out. The user would then navigate back to the front-end application and add another item and submit the order again. Since the user is submitting an…
If the second request is different, then idempotency doesn't apply.