Share this comment
I like the post but unfortunately it has a few errors. Based on docs.stripe.com/api/ide… i see:
- "So they create a unique string (UUID) to use as the idempotency key."
It is clear from Stripe doc that the client is responsible for generating UUID - and it can potentially be whatever. On other page they provide 2 strategies which can be us…
I like the post but unfortunately it has a few errors. Based on https://docs.stripe.com/api/idempotent_requests i see:
- "So they create a unique string (UUID) to use as the idempotency key."
It is clear from Stripe doc that the client is responsible for generating UUID - and it can potentially be whatever. On other page they provide 2 strategies which can be used to generate UUID.
- "Also they generate a new UUID whenever the request payload changes." - it is again client responsibility to generate a new UUID for logical new request. Stripe itself provides some safety net meaning that it seems like they store in their in-memory DB a pair: UUID -> request parameters. And they return error when a new request come with same UUID but different parameters.
Another thing is when to put stuff in in memory-db and in general how to keep consistent view of 2 datasources: ACID db and in-memory DB. In stripe doc they claim "We save results only after the execution of an endpoint begins" but according to their design "request parameters validation" and "request conflicts with another request" discovery are not part of API endpoint logic so if any of conditions above fails they do not store UUID in in-memory DB and client can retry request without any problem. So can be they put UUID with parameters in in-memory db before "true" endpoint logic is executed. Probably they update in-memory DB with response status for given UUID after api endpoint is executed.