[ramchip]

You can use the DB for this as well, just make a table e.g. "requests" with two columns, the user and the request token. Old entries can be purged on a cron job.

If you add a column to store params as well then you can also do better validation:

> Responding when a customer changes request parameters on a subsequent call where the client request ID stays the same

> We design our APIs to allow our customers to explicitly state their intent. Take the situation where we receive a unique client request token that we have seen before, but there is a parameter combination that is different from the earlier request. We find that it is safest to assume that the customer intended a different outcome, and that this might not be the same request. In response to this situation, we return a validation error indicating a parameter mismatch between idempotent requests. To support this deep validation, we also store the parameters used to make the initial request along with the client request identifier.

https://aws.amazon.com/builders-library/making-retries-safe-...

[jongjong]

You can but you add an additional database lookup step which will cost you more in performance (and latency) than just using UUIDs as the ID directly with a single table.

[ramchip]

It's only at creation time. When you lookup the record after that you can use the ID directly, and then you don't hit the locality problems from the article.