Idempotent Operation In Distributed System

In my previous article, we learned something about “Exactly once Semantics” in communication, where it says that the message from the client should be received at the server exactly once, as no duplicate is reliable in a communication network. In this article, we will learn one more aspect of “Exactly once semantics,” which is Idempotent Operation.

To start with – What is idempotent Operation??

Idempotent means the “same thing” and idempotent operation is something like – the operation which produces the same result over and over, no matter how many times the operation you perform with the similar arguments and also without any side effects. For example - GetSqrt procedure is for calculating the root of a given number. GetSqrt(81) will always give you 9. This is idempotent operation, it always gives you the same result.

To understand these operations, let’s consider one example here. Let’s say a client has ₹1000 in his account and now he wants to withdraw ₹100 from it. We will see this whole transaction with a non-idempotent operation first and then, we will move on to the idempotent operation so that you can understand the difference.

Steps 1

Client requests Server to process the debit of ₹100 from his account. For this, the client makes a request message as – Request Debit(100).

Step 2

This process on the Server side should be like – 1000-100 = ₹900 left in the client account.

Step 3

After processing, the Server sends a response message as – Return (Success, 900) to client.

Now, let’s consider a case where the above Return Reply message gets lost in the connection, definitely with the timeout mechanism. The client will wait for the reply from the Server for a specific time and after that, it assumes the request message has gotten lost and therefore retransmission is needed. So, he will retransmit the same request to the Server – this is the same thing we had seen in our previous article of exactly once semantics, and this is not a reliable way to communicate.

Step 4

Now what happens is that the client sends the same request again as Retransmit (Debit, 100).

Step 5

On the server side, the server assumes it as a new request message, and treats it like that – Balance = 900-100 = 800. You see here, 100 is deducted twice, but the client wants to debit only ₹100. So we are very off in this communication path.

Step 6

The Server sends a reply message as Return (Success, 800) to the client.

Non-Idempotent Operation

                     

In Idempotent Operation, the Server has a “Reply Cache” by which it can refer the incoming request. If the request is there in the reply cache, then it processes that request from a previously left state.

Idempotent Steps

1. The client makes a request as – Request -1 - Request (Debit, 100)
2. The Server receives the request as – Request 1 that it processes. First, the Server checks in the reply cache if the request is already referred by it or not.
   
   

   Request Identifier	Reply to be Sent
   - Null	-Null

   
   
3. The Server initially does not find any reference to Request 1 and it assumes the request as a fresh one from the client. Then, it forwards the request to the appropriate Server.
   
   
4. The Server processes the request as Balance 1000-100 = 900 and sends this as a response message back to the client. Also, the Server kernel copies the Request Identifier and the result to the Reply Cache.
   
   

   Request Identifier	Reply to be Sent
   Request-1	Success,900

   
   
5. Let’s say this response gets lost in between the communication, and after a specific time out, the client will retransmit the request.
   
   
6. Client Retransmit the request -1 again to the server as – Retransmit (Debit, 100).
   
   
7. Server receives the request but before processing that request, it will see the reply cache. At this time, it has found a match, so it will not assume this request as the fresh one. And, according to the last state of the request, it will process the request – In our case, it will reply the result as – Return (Success , 900).
   
   As you can see, the duplicate request doesn’t deduct ₹100 twice as in our non-idempotent operation.
   
   
   

Thus with the exactly once semantics, an idempotent operation can avoid the duplicate request. Hope you enjoyed this. Thank you for reading.