undefined | Better HN

0 pointschii13h ago0 comments

In my opinion, the idea of idempotency is to accept both requests, but only one is actioned (and the requester is non-the-wiser about which). Otherwise, you're just recreating database transactions - something that doesn't need to be named idempotency.

And you haven't considered multiple servers in your scenario - what if two requests meant to be idempotent with each other arrived at different servers?

0 comments

yladiz13h ago

How would the requester get notified if it doesn’t know which request succeeded? Is it listening for events?

And at the sake of repeating the above commenter, you solve the multiple server by serializing somewhere, because you ultimately need a lock on something. You can also perform the operation in both places and then reconcile the state later but that’s a lot more complex.

jmalicki10h ago

The requester doesn't want to know which request succeeded, because they are duplicates and one is a retry!

When you are using TCP, and you send the same data twice because of a delayed ack, you likewise don't care if the ACK is for the first time or the second time you sent the data. You just know the other side got the data, and that's all you care about.

thaumasiotes12h ago

> How would the requester get notified if it doesn’t know which request succeeded?

By sending a third request and getting a response that reveals the state of the system.

yladiz11h ago

Seems like more overhead than just getting a response from the initial request.

1 more reply

j / k navigate · click thread line to collapse