Idempotency in Backend Development: Concepts, Importance, and Implementation Strategies

1. Overview

When developing order systems, payment issues often arise where a successful deduction is followed by a network error, leading users to retry and cause duplicate charges.

In single‑application systems, wrapping data operations in a transaction is enough, but network interruptions during response can still break consistency; idempotency is needed to guarantee that the entire order lifecycle remains unchanged despite exceptions.

2. What is Idempotency?

Idempotency is a mathematical and computing concept; an idempotent function returns the same result when invoked repeatedly with the same parameters and does not change system state.

Idempotency: any number of executions have the same effect on the resource as a single execution.

For APIs, idempotency means that repeated calls produce the same outcome; read‑only queries are naturally idempotent, while INSERT and UPDATE are not and require mechanisms to avoid side effects.

3. Key Points of Idempotency

Idempotency is not only about having no side effects on repeated requests.

It may allow a first request to have side effects, but subsequent identical requests must not cause additional effects.

The focus is on the effect of later requests, not on the result value.

Network timeouts are outside the scope of idempotency discussion.

4. Why Idempotency Matters

Duplicate submissions occur due to network issues or UI glitches, leading to problems such as multiple orders, double payments, or duplicate outbound records.

User clicks submit multiple times – only one order should be created.

Payment gateway (e.g., Alipay) should deduct money only once even if the request is retried.

Repeated outbound requests should not generate multiple shipping documents.

5. Common Techniques to Ensure Idempotency

5.1 MVCC (Multi‑Version Concurrency Control)

Use conditional updates with version numbers or timestamps to prevent lost updates.

select * from tablename where condition=#condition# // fetch object with version
update tableName set name=#name#, version=version+1 where version=#version#

Optimistic locking with retries can handle concurrent updates.

5.2 Deduplication Table

Insert a unique key (e.g., order ID) into a table with a unique index; if a duplicate insert occurs, the database throws a constraint violation and the transaction rolls back.

5.3 SELECT … FOR UPDATE

Lock the target row during processing; suitable when reads dominate writes.

5.4 SELECT + INSERT

For low‑concurrency jobs, first check if the operation has already been performed before proceeding.

5.5 State‑Machine Idempotency

Model business processes as finite state machines; once a resource reaches a later state, earlier‑state transitions are ignored.

5.6 Token Mechanism

Generate a one‑time token stored in Redis or JVM memory; the token is validated and removed on submission to prevent duplicate requests.

5.7 API Design with Source+Seq

Payment APIs require a source identifier and a sequence number; a composite unique index prevents multiple deductions.

5.8 Global Unique ID

Generate a globally unique identifier for each operation; check its existence before execution to guarantee single execution.

6. Summary

Idempotency adds extra control logic, potentially reducing throughput, but it is essential for data correctness in distributed systems, especially in financial or order‑processing services.