Understanding Idempotency: Concepts, Examples, and Implementation Techniques

Idempotency (idempotent, idempotence) originates from mathematics and abstract algebra and is widely used in programming to describe operations whose effect remains the same no matter how many times they are executed with the same parameters.

In code, an idempotent function can be called repeatedly with identical arguments and will always produce the same result without altering system state; for example, getUsername() and setTrue() are idempotent.

In plain terms, an operation is idempotent if executing it multiple times yields the same outcome as executing it once.

Examples

1. Repeated form submissions from the front‑end should generate only one result on the back‑end.
2. A payment request should deduct the user's account only once, even if the network or system retries.
3. Sending a message should happen only once; duplicate SMS would overwhelm the user.
4. Creating a business order should result in a single order, not multiple.

These scenarios all rely on idempotent behavior.

Technical Solutions for Idempotency

Query Operations

Querying the same data multiple times without changes yields identical results; SELECT is naturally idempotent.

Delete Operations

Delete is idempotent: deleting once or multiple times results in the data being removed (the return value may differ, e.g., 0 rows affected if already deleted).

Unique Index to Prevent Duplicate Data

-- Example using Spring exception for duplicate key
org.springframework.dao.DuplicateKeyException
-- Insert fails if a unique index on user_id already exists, ensuring only one account per user.

Token Mechanism to Prevent Duplicate Submissions

Require a token before submitting data; store the token in Redis or JVM memory with a short TTL.
After submission, the back‑end validates and deletes the token, then issues a new one.
Use DELETE on Redis to verify token validity; avoid SELECT+DELETE due to concurrency issues.

Pessimistic Lock

SELECT * FROM table_xxx WHERE id='xxx' FOR UPDATE;
-- Ensure the id column is a primary key or unique index to avoid table‑level locking.

Optimistic Lock

-- Version‑based update
UPDATE table_xxx SET name=#name, version=version+1 WHERE version=#version#;
-- Conditional update to ensure sufficient amount
UPDATE table_xxx SET avai_amount=avai_amount-#subAmount# WHERE avai_amount-#subAmount# >= 0;
-- Use primary key or unique index in the WHERE clause to avoid full‑table locks.

Distributed Lock

When a global unique index is hard to define, introduce a distributed lock via Redis or Zookeeper: acquire the lock before inserting or updating data, perform the operation, then release the lock to control concurrent writes.

Select + Insert Pattern

For low‑concurrency jobs, first query key data to check if the operation has already been performed, then proceed; this pattern should not be used for high‑throughput critical paths.

State‑Machine Idempotency

Design business documents with a finite state machine; if a request tries to move an entity to a previous state that has already advanced, reject it, thereby guaranteeing idempotent state transitions.

API Idempotency for External Calls

External payment APIs (e.g., UnionPay) require callers to include a source and a seq (sequence number). Create a composite unique index on these fields so repeated requests are detected and ignored.

Final Summary

Idempotency is a fundamental trait for competent programmers; it should be considered first when designing systems, especially in financial, payment, and internet‑banking platforms where duplicate operations can cause severe issues.