Stripe, for example, will provide an idempotency key, so that you can safely retry a request if something goes wrong in transit.
Usually, if the operation takes place in the realm of your stack, it will be fully on your hands to meet idempotency requirements. The unique identifier principle explained above will usually be enough. But if you’re relying on third-party APIs, it might be tricky to ensure idempotency and you might need help from the other party to accomplish this goal, in case this kind of operation isn’t supported out of the box. If you can’t get the third party to work with you, there’s always the possibility to run all operations on your end first, create a separate process to check whether everything ran successfully, then interact with the external API. This wouldn’t be the ideal implementation but could be as good as one can get in some circumstances.
A serverless developer needs a tool that automatically identifies when an invocation is actually a retry from a previous execution. That is why we created Dashbird and offer it for free to all serverless developers. The first execution and subsequent retries are linked by our system, so they are easily navigable. This makes it a lot easier to understand why a function is failing and whether the idempotency strategy implementation is working properly.
Failure detection, analytics and visibility for serverless applications in under 5 minutes.