Idempotency Strategies: Preventing Duplicate Operations in High‑Traffic Systems

Background

In many real systems, operations should produce the same effect or return the same result no matter how many times they are performed. Examples include preventing duplicate data submissions from the front end, ensuring a payment request deducts money only once, sending a message only once, and creating a business order only once.

Idempotency Concept

Idempotence (idempotent) is a mathematical and computer‑science concept, often seen in abstract algebra. In programming, an idempotent operation yields the same impact whether executed once or many times. An idempotent function returns the same result with the same parameters on repeated calls and does not change system state.

Complex operations achieve idempotence by using a unique transaction identifier (serial number).

Technical Solutions

Query Operations – Queries are naturally idempotent; repeated selects return the same data when the underlying data does not change.

Delete Operations – Deleting the same record multiple times is idempotent; subsequent deletions may return different counts (e.g., 0 if the record no longer exists).

Unique Indexes – Adding a unique constraint (e.g., one financial account per user) prevents duplicate creation of records.

Token Mechanism – Use a token stored in Redis or JVM memory to ensure a page can be submitted only once. The flow: request a token before submission, include it in the request, backend validates and deletes the token, then issues a new token.

Pessimistic Lock – Acquire a row lock with SELECT * FROM table_xxx WHERE id='xxx' FOR UPDATE;. The lock column must be a primary key or unique index to avoid table‑wide locking.

Optimistic Lock – Update only if a version number matches, e.g.:

UPDATE table_xxx SET name=#name#, version=version+1 WHERE version=#version#

or use conditional updates to ensure inventory never goes negative.

Distributed Lock – In a distributed system, obtain a lock from a third‑party service (Redis, Zookeeper) before inserting or updating data, then release the lock after the operation.

Select‑then‑Insert – For low‑concurrency jobs, first query to see if the operation has already been performed before proceeding.

State‑Machine Idempotence – Design business processes as finite state machines; if a request tries to move to a previous state, reject it, ensuring state transitions are idempotent.

API Idempotence – Require callers to provide a source identifier and a sequence number (source+seq) that are stored as a composite unique index, preventing duplicate processing of the same request.

Conclusion

Idempotency should be a core consideration for any qualified programmer when designing systems, especially in financial domains where duplicate charges or messages can cause serious issues. Proper use of unique constraints, tokens, locking mechanisms, and idempotent API design ensures both efficiency and data accuracy.