Idempotence Design in Distributed Systems

Problem Description
In distributed systems, especially in scenarios involving network communication, service calls, or message queues, the same request or operation may be executed multiple times due to reasons like network timeouts, service retries, or duplicate message deliveries. Idempotence design refers to the system's ability to ensure that the result of executing the same operation once or multiple times remains consistent. It prevents business anomalies such as data inconsistency or duplicate deductions caused by multiple executions. For example, repeated calls to a payment interface should not result in the user being charged twice. This is one of the core design principles for high-performance and highly reliable backend systems.

Solution Process

1. Understanding the Core Challenges of Idempotence
First, you need to understand why idempotence is necessary. In a single request, if the server processes successfully but the network times out, the client, unable to receive a response, typically initiates a retry. Without idempotence design on the server side, retries may lead to:

• Duplicate data insertion (e.g., creating multiple orders).
• Repeated resource deduction (e.g., reducing the balance multiple times).
• Business state confusion (e.g., duplicate order payments).

Key point: Idempotence focuses on the result, not the process—even if an operation is executed multiple times, the final state should be the same as if it were executed once.

2. Identifying Scenarios Requiring Idempotence
Not all operations require idempotence. The following typical scenarios must be designed with idempotence in mind:

• HTTP POST/PUT: Creating or updating resources (e.g., submitting orders, payment requests).
• Message Queue Consumption: Consumers may reprocess the same message after a crash and restart.
• Scheduled Task Retries: Task schedulers may retrigger tasks due to timeouts.
• Compensation Operations in Distributed Transactions: Such as refunds or inventory rollbacks, which must be executed only once.

3. Designing Key Technical Solutions for Idempotence
Next, we explain common methods to achieve idempotence step by step, from simple to complex:

Step 3.1 Database Level: Unique Constraints and Optimistic Locking

• Unique Index for Duplicate Prevention:
  For creation operations (e.g., generating orders), add a unique database index for the business-unique identifier (e.g., order number). When duplicate requests attempt to insert the same data, the database throws a unique constraint violation exception. Subsequent insertions fail, but the data state remains unchanged.
  Example: Set a unique index on the order_id column in the orders table. Duplicate insertions will fail without creating a new order.

• Optimistic Lock Updates:
  For update operations (e.g., deducting inventory), add a version number field (version) to the data table. During updates, verify the version number to ensure updates occur only when the version matches:

  UPDATE inventory SET quantity = quantity - 1, version = version + 1
  WHERE product_id = '123' AND version = 1; -- Update only if version is 1
  

  Duplicate requests will fail due to version mismatches, achieving idempotence.

Step 3.2 Business Level: State Machines and Token Mechanisms

• State Machine Constraints:
  Define business state transition rules (e.g., "pending payment → paid" is irreversible). Before executing an operation, validate the current state. If already in the target state, return success directly.
  Example: After successful payment, the order state changes to "paid." Duplicate payment requests detect this state and return success directly, avoiding duplicate deductions.

• Token Mechanism:

  1. The client first requests a unique Token (e.g., UUID) from the server. The server stores the Token in a cache with a short expiration time.
  2. The client sends a business request carrying the Token. The server validates whether the Token exists:
     • Exists: Execute the business logic and delete the Token (or mark it as used).
     • Does not exist: Reject the request (treated as a duplicate).
       Key: Token generation, validation, and deletion must be atomic (e.g., using Redis's SETNX command) to avoid concurrency issues.

Step 3.3 Distributed System Level: Global Unique ID and Idempotence Table

• Global Unique Request ID:
  Assign a globally unique ID (e.g., generated by the Snowflake algorithm) to each request. The server records the request_id and business result in an idempotence table. When a duplicate request arrives:
  • If the same request_id exists and succeeded previously, return the previous result directly.
  • If it does not exist or failed previously, execute the business logic and record the result.
    Note: The idempotence table must have a unique index on request_id. Concurrent requests can ensure atomicity through database uniqueness constraints.

4. Practical Considerations

• Coordinating Timeouts and Retries: Clients should use the same request ID for retries. Servers need to set reasonable timeout periods to avoid concurrency issues caused by retries during business execution.
• Cleanup Strategy: Idempotence data (e.g., Tokens, request records) should have expiration times to avoid long-term storage pressure.
• Distinguishing Business Semantics: For example, "deduct $10" is idempotent, "query balance" is naturally idempotent, while "send SMS" is not idempotent (business requirements determine if duplicate sending is allowed).

Summary
Idempotence design requires selecting appropriate solutions based on business scenarios: use database constraints for simple scenarios, Tokens or global IDs for high concurrency, and ultimately ensure result consistency through state validation, unique identifiers, and atomic operations. In practice, multiple solutions (e.g., "optimistic locking + state machine") are often combined to cover edge cases.