Prevent duplicate effects when clients retry requests after timeouts or network failures.
The core idea
An operation is idempotent when repeating it has the same intended effect as performing it once. Network clients cannot always tell whether a timed-out request reached the server, so retry-safe design matters.
A practical way to approach it
For operations such as payments or order creation, accept an idempotency key, store the result associated with that key, and reject reuse with conflicting input. Define key scope and retention, and ensure the database transaction protects the record and side effect.
Try it in a small project
Simulate a client timeout after a successful order creation, then retry with the same key. The API should return the original order rather than creating a second one.
Common mistakes to avoid
Do not rely on disabling a button in the UI. The server must enforce idempotency, and keys should not expose sensitive information.
Key takeaway
Keep the first version small, make your assumptions explicit, and verify the result with a repeatable test. For production use, check the current official documentation for the tools and versions you choose.