Idempotence Design in Distributed Systems

Problem Description
In distributed systems, due to network latency, node failures, or retry mechanisms, the same operation request may be sent to the server multiple times. Idempotence design refers to a system's ability to ensure that the effect of executing the same operation multiple times is identical to the effect of executing it once. For example, repeated calls to a payment interface should not result in the user being charged multiple times. Idempotence design is one of the core elements of fault tolerance in distributed systems and requires collaborative implementation from the client side to the server side.

Step-by-Step Explanation of the Solution Process

1. Understanding the Essence of Idempotence

   • Core Definition: An operation is idempotent if its result is exactly the same (side effects occur only once) whether it is executed once or multiple times.
   • Common Scenarios:
     • HTTP Requests: Methods like GET, PUT, DELETE are typically idempotent, while POST is not.
     • Business Operations: Payment/order placement, status updates (e.g., setting "paid"), data deletion.
   • Examples of Non-Idempotent Operations: Creating a new order, accumulating account balance (e.g., balance += 100).

2. Key Issues in Implementing Idempotence

   • Request Deduplication: How to identify duplicate requests? Requires marking the same business operation with a unique identifier (e.g., Request ID).
   • State Management: The server needs to record the status of processed requests to avoid repeatedly executing business logic.
   • Concurrency Control: When multiple duplicate requests arrive simultaneously, consistency must be ensured through locks or atomic operations.

3. Step-by-Step Analysis of Implementation Solutions
   Step 1: Generate a Unique Request Identifier (Request ID)

   • The client generates a globally unique ID (e.g., UUID, Snowflake ID) when initiating a request and passes it in the request header or parameters.
   • Requirement: Repeated requests for the same business operation must use the same Request ID (e.g., use the initial request's ID for payment retries).

   Step 2: Server Checks if the Request Has Been Processed

   • Upon receiving a request, the server first queries the storage system (e.g., Redis, database) to see if a record for this Request ID exists:
     • If it exists and has been successfully processed: Directly return the previous processing result without executing business logic.
     • If it exists but is still being processed: Block subsequent duplicate requests using a status marker (e.g., "processing") and wait for the previous request to complete.
     • If it does not exist: Mark the Request ID as "processing" and execute the business logic.

   Step 3: Atomically Execute Business Logic and Update Status

   • Use database transactions or distributed locks to ensure the atomicity of the following operations:
     1. Check the status of the Request ID.
     2. Execute the business operation (e.g., update the database).
     3. Update the Request ID status to "completed" and store the result.
   • Example flow:

     BEGIN TRANSACTION;  
     SELECT status FROM request_ids WHERE id = 'req_123';  
     -- If not processed, insert record and update business data  
     INSERT INTO request_ids (id, status, result) VALUES ('req_123', 'processing', NULL);  
     UPDATE accounts SET balance = 100 WHERE user_id = 1; -- Idempotent update (setting a fixed value)  
     UPDATE request_ids SET status = 'success' WHERE id = 'req_123';  
     COMMIT;  
     

   Step 4: Handle Edge Cases

   • Timeout and Retry: If the client does not receive a response, retry requests must carry the same Request ID.
   • Storage Failure: If the server crashes before saving the status, it may lead to repeated execution. Therefore, status saving and business operations must be placed within the same transaction.
   • Expiration Cleanup: Periodically clean up old Request ID records to avoid storage bloat (e.g., set Redis expiration time).

4. Adaptation Strategies for Different Scenarios

   • Query Operations: Naturally idempotent, no additional handling required.
   • Write Operations:
     • Replacement Updates: Use UPDATE table SET value = new_value instead of value = value + increment.
     • Version Control: Avoid concurrent repeated execution through optimistic locking (e.g., CAS operations).
   • Message Queue Consumption: Include a unique ID in the message, record the ID after consumption to ensure duplicate messages are filtered.

5. Architecture Design Considerations

   • Storage Selection: Redis is suitable for high-frequency, short-term requests; databases are suitable for long-term persistence.
   • Distributed Environment: Distributed locks (e.g., Redis locks) are needed to ensure safety across nodes under concurrency.
   • Performance Trade-offs: Request checks may increase latency, which can be optimized through asynchronous recording or batch processing.

Through the above steps, the system can effectively identify and filter duplicate requests, thereby achieving idempotence for business operations in a distributed environment.