Understanding Idempotence: Definition, Importance, Common Causes, and Practical Backend Solutions

Definition of Idempotence

Idempotence is a mathematical and computer science concept meaning that performing the same operation once or multiple times yields consistent results without side effects. In programming, an idempotent operation can be executed repeatedly with the same parameters, and the impact on the system remains identical each time.

Why Implement Idempotence

In distributed systems and network communications, idempotence is crucial to prevent duplicate data or lost updates. Developers must consider idempotence especially in scenarios involving monetary transactions such as transfers and payments, where failures can have severe consequences.

Common Causes of Non‑Idempotence

Network fluctuations leading to repeated request submissions.

Malicious users performing duplicate orders (刷单).

Interface timeout retries.

Scheduled task retries.

Duplicate consumption when using message queues.

How to Achieve Idempotence

Two general approaches are commonly used:

Require downstream systems to provide a query interface; before retrying a timed‑out operation, query the downstream system to determine if the previous call succeeded.

Delegate the idempotent guarantee to the downstream system, which ensures that one or many requests produce the same result.

Solution 1: Database Unique Index

Before inserting data, perform a select to check existence; insert only if the record does not exist. In high‑concurrency scenarios, two requests might both miss the record and attempt insertion, so a unique index is added to the database to enforce idempotence.

Solution 2: Anti‑Duplicate Table Mechanism

This approach creates a separate anti‑duplicate table with a unique index. The unique key is inserted into the anti‑duplicate table within the same transaction as the business operation. If a duplicate request occurs, the unique constraint causes the transaction to fail, preventing duplicate processing. The anti‑duplicate table and business table must reside in the same database and be handled in a single transaction.

Solution 3: Optimistic Lock

Applicable to update operations, this method adds a version column to the table. The version is read with the data; on update, the version is incremented. The update succeeds only if the submitted version matches the current version in the database.

update account set amount = amount - 50, version = version + 1 where id = 123 and version = 1;

Solution 4: Pessimistic Lock

Pessimistic locking relies on the database's lock mechanism, typically using SELECT ... FOR UPDATE to lock the row during the transaction.

select * from account where id = 123 for update;

The id field must be a primary key or have a unique index; otherwise, the lock may affect the entire table and degrade performance.

Solution 5: Anti‑Duplicate Token

This approach involves two request phases: (1) the client requests a token from the server; (2) the client includes the token in the subsequent request, and the server validates the token before performing the operation.

Solution 6: Distributed Lock

A distributed lock, often implemented with Redis, attempts to acquire a lock using a business‑unique ID for each request. If the lock is obtained, the request proceeds; otherwise, it is rejected.

Solution 7: State Machine

When business processes have defined state transitions (e.g., order status 1‑ordered, 2‑paid, 3‑completed, 4‑canceled), the state machine ensures idempotence by updating to the next state only if the current state matches the expected previous state.

update order_info set status = 3 where id = 123 and status = 2;