Questions

[ivan-zaitsev]

What will happen if the fist requst didn't finished yet but the second request with the same idempotency key is sent?

What will happen if after starting processing the first request the service node dies and after that the second request with the same idempotency key is send?

[ivan-zaitsev]

For the first one I see that library just returns null - here. Don`t you think that it is better to wait and ask the storage if the request is finished (to hold the request) or at least throw an exception ("in progress" status code) to the client that it could retry the request (to accomplish similar logic).

For the second one, don`t you think that it is better to add some "lock" time for which idempotent key is considered as "in progress", and here is when other clients try to send the second request, we just fallback to the first problem what I pointed.

This way when you have a "lock" you can extend it if the first request running too much time, subsequent requests just waiting relying on this "lock" (or just respond instantly with "in progress" status code), also if the first request dies, when this "lock" expires, other requests can quietly start doing job from the beginning

[ivan-zaitsev]

Here is a good library with ideas of locking scheduled tasks. It is different from idempotency, but anyway it has good code snippets (at most lock logic, extending locks logic).

[nnddnn]

There is a comment in this article, the meaning of which is that Redis is not very suitable for this task. What do you think about this?