The story of one idempotent method

Hello! My name is ProcessPaymentand i is an idempotent method designed to reliably process payment requests. My job is to accept requests, write off money and, most importantly, avoid duplication of transactions. There were many stages along the way to this goal, each of which made me stronger and more reliable. Let me tell you how it was.

1. Statement of the problem and the need for idempotence

When they started developing me, the main task was processing payment requests. Clients sent a POST request for a charge, and I had to process it without creating duplicates. In the event of a network failure or accidental re-sending, the request could arrive again and this could result in multiple charges. So there was a need to make me idempotentso that the result remains unchanged during any repetitions.

2. Generation and transmission of Idempotency-Key

In order to distinguish requests from each other, the developers added a unique identifier to the header of each request Idempotency-Key. This key, which was generated by the client (usually a UUID), became a unique “fingerprint” of each request. If a client accidentally resent a request, I could tell by Idempotency-Key and prevent re-processing.

3. Setting up a key storage

After the appearance Idempotency-Key we needed a place to store it. We chose Redis, a high-speed storage solution suitable for temporary data. With each new request I saved Idempotency-Key along with the result of the operation. If a request with the same key came again, I could simply return the already saved result, avoiding unnecessary work. Redis also made it possible to configure automatic record deletion via TTL to free memory from obsolete data.

4. Error handling in case of storage failures

Although Redis is reliable, any system can fail temporarily. So I learned to check the storage status before processing each request. If Redis was unavailable I would return an error code to the client 503 Service Unavailablewarning that the request cannot be completed right now. The client was advised to repeat the request later to avoid idempotency violations.

5. Logic for processing repeated requests

Every time I received a request with Idempotency-KeyI was checking if this key exists in Redis. If the key was found, it meant that the request had already been processed, and I could immediately return the saved result to the client. If the key was missing, the request was considered new and processed, saving the result for possible repetitions. For added security, I stored a hash of the request data, which helped ensure that each key was used correctly.

6. Retry Policy and Timeouts

To prevent the client from sending requests too frequently when Redis is temporarily unavailable, a timeout policy was implemented. If the server returned an error 503the client had to wait before resending. This reduced the load on the server and prevented requests from queuing, helping me maintain stability.

7. Monitoring and logging

To control the operation of the method, monitoring and logging were configured. The system monitored the availability of Redis and recorded errors, allowing failures to be quickly resolved. The logs helped analyze problematic queries and optimize my work.

Conclusion

All these technical measures made me reliable and resistant to repetition. Today, thanks Idempotency-KeyRedis storage, error handling and monitoring, I process requests consistently while ensuring duplication protection.

My story shows that idempotency is a whole system of mechanisms that creates stable methods and protects against random errors.

My channel for beginner systems analysts – “Mom, I'm a team leader!”