May be in "Using Idempotency Key to Prevent Double Payment“ diagram. What if at the step 2,the server successfully store the idempotency key to in-memory DB, but it failed to make network request to the ACID DB at step 3?
I was thinking that too. Communication failure between cache and ACID db. I imagine they would have a unique constraint on the actually DB for idempotency in the event of 2 requests sent too closely for the in-memory cache to update and reject the request.
I wonder how to ensure the consistency of the step 2 and 3 above.
what steps are you referring to?
May be in "Using Idempotency Key to Prevent Double Payment“ diagram. What if at the step 2,the server successfully store the idempotency key to in-memory DB, but it failed to make network request to the ACID DB at step 3?
I see, I don't have insights to their implementation details. But I'd guess:
1) they store the idempotency key only after ACID DB passes the request.
2) Or remove the idempotency key if ACID DB fails the request.
Does that help? Perhaps I'm overseeing some details or misunderstood the question.
I was thinking that too. Communication failure between cache and ACID db. I imagine they would have a unique constraint on the actually DB for idempotency in the event of 2 requests sent too closely for the in-memory cache to update and reject the request.