Understanding Idempotency: Definitions, Scenarios, and Implementation Strategies

1. Business Scenarios

Typical situations that may trigger duplicate actions include user repeated order submissions, repeated payments, and transfer retries.

2. What Is Idempotency

Idempotency (idempotent, idempotence) originates from mathematics, where a function satisfies f(x) = f(f(x)). In programming, an idempotent operation yields the same effect no matter how many times it is executed with the same parameters. Examples include functions like abs(x) or a setTrue() method.

3. Idempotent Scenarios

Natural idempotent cases: Read‑only queries are inherently idempotent because they do not modify state.

Cases requiring idempotency: Calls to downstream write APIs, database writes (CRUD), Redis updates, and message subscription handling.

How to achieve idempotency in CRUD operations:

INSERT example: insert user values (uid, name, age, sex, time) (use business key or unique index).

SELECT example (naturally idempotent): select * from user where uid=3 UPDATE example (idempotent when setting absolute value): update user set age = 18 where uid=3. Relative updates like update user set age = age + 1 where uid=3 are not idempotent.

DELETE example (often replaced by soft delete): delete from user where uid=3 or batch delete delete from user where uid in (…).

4. Common Problems

Redundant deployment of multiple services and concurrent processing can cause duplicate handling. The typical solution is to serialize concurrent requests using distributed locks.

5. Case Studies

Case 1: Message read status – naturally idempotent.

Case 2: Incrementing age by one – convert relative increment to absolute update (e.g., set age=19 where age=18).

Case 3: E‑commerce purchase flow – includes order creation, payment, and status updates, requiring distributed transaction handling.

6. Summary – How to Ensure Idempotency

State‑based idempotency: Allow operation only when pre‑conditions are met (e.g., reject duplicate payment after order is already paid).

Unique‑key based idempotency: Use business‑related keys such as product ID, order ID, user ID, or a combination thereof. Global unique IDs (e.g., Snowflake) can also serve as idempotency keys. For updates, include a version number to avoid ABA problems.

Implementation tip: Create a unique index on the idempotency key in MySQL for strong guarantees; avoid relying solely on Redis because of potential node failures.

Message‑queue idempotency: Since MQ may deliver messages multiple times, add a lock before processing. If the lock is acquired, proceed; otherwise, retry later. Use the lock’s TTL as the lock lease period.