Backend
Idempotency
Designing an operation so that repeating it has the same effect as doing it once — essential because networks retry and a client often cannot tell whether the first call succeeded. Achieved with an idempotency key the server records, or naturally idempotent verbs like PUT and DELETE. Without it, retried payments or orders get duplicated.
Purpose
An idempotent operation produces the same result whether it runs once or many times. It matters because networks are unreliable: a client that times out cannot tell whether its request succeeded, so it retries — and without idempotency that retry double-charges or double-creates.
When to Use It
Essential for payments, order creation, and any state-changing call made over a flaky network or through a retrying queue. GET, PUT and DELETE are naturally idempotent; POST is the dangerous one.
It is the safety net that makes automatic retries and at-least-once queue delivery safe.
Trade-offs
It requires extra machinery — keys, dedup storage and expiry — and careful thought about what 'same effect' means. The payoff is correctness under retries, which is non-negotiable for money and orders.
Implementation
Have the client send an idempotency key (a UUID) with each mutating request; the server records the key with its result and, on a repeat, returns the stored result instead of acting again. Keep keys for a sensible window, and lean on naturally idempotent verbs (PUT, DELETE) where you can.