Idempotency — what a word.

I'll admit the first time I saw it was in an AI coding session, and it took me a while to figure out the pronunciation, let alone understand how to apply it.

An operation is idempotent when running it twice leaves the system exactly as if you'd run it once. Clear, right? No?

Here's an example.

Have you ever accidentally clicked "add to basket" more than once, and then were surprised to see your order total double? That's not idempotent behaviour.

Which is fine for that particular operation. But what about something like this:

A ticket gets closed in one system → your integration creates an invoice draft in another system.

Except then someone comes, opens and closes the same ticket again → and the integration creates another invoice draft.

Same failure, but here it matters. So how do you implement it better?

Make the system check if this specific ticket already triggered a successful invoice creation before. On draft creation, write the invoice number back into the ticket. Then set a condition to stop draft creation if that number already exists in the ticket.

This pattern has a name → an idempotency key. Proof that the operation already happened, so the system knows not to do it again.

The price has changed and you do want a new draft? No problem → remove the invoice number, or build in an override condition.

So idempotency comes down to asking this question: what happens if this fires twice? And, does the effect matter?

What's the operation in your system that would double-charge, double-book, or double-create if it fired twice?