Ensuring Idempotency in Distributed Systems: Strategies and Code Examples

Background

Many operations in real systems must produce the same effect regardless of how many times they are executed, such as preventing duplicate submissions, double charging, repeated messaging, or duplicate order creation.

Idempotency Concept

Idempotent operations yield identical results no matter how many times they run. In programming, an idempotent function returns the same output for the same input without changing system state. Examples include simple queries and certain update patterns.

Technical Solutions

Query operations – SELECT statements are naturally idempotent when data does not change.

Delete operations – Deleting an already‑deleted record is still safe; the result may differ (0 rows vs. multiple rows).

Unique indexes – Adding a unique constraint (e.g., one financial account per user) prevents duplicate inserts.

Token mechanism – Generate a token stored in Redis or JVM memory, require the token for each submission, validate and delete it on the server side, then issue a new token.

Pessimistic lock – Use SELECT ... FOR UPDATE on a primary‑key or unique index to lock rows during a transaction.

Optimistic lock – Include a version column or conditional check in the UPDATE statement, e.g.:

update table_xxx set name = #name#, version = version+1 where version = #version#

or

update tablexxx set avaiamount = avaiamount-#subAmount# where avaiamount-#subAmount# >= 0

Distributed lock – Acquire a lock from Redis or Zookeeper before inserting or updating data, then release it after the operation.

Select‑then‑insert – For low‑concurrency jobs, first check whether the record already exists before performing the insert.

State‑machine idempotency – Model business processes as finite state machines; transitions that would move to a previous state are rejected, guaranteeing idempotent behavior.

API design – Require callers to provide a source identifier and a sequence number (seq); store a composite unique index on these fields to reject duplicate requests.

Conclusion

Idempotency is a fundamental trait for reliable software, especially in financial systems where duplicate operations can cause severe issues. Applying unique constraints, tokens, locks, version checks, or state‑machine validation helps ensure that repeated requests have no adverse effect.