Idempotency a key term in distributed systems Software Engineering Dictionary

>> YOUR LINK HERE: ___ http://youtube.com/watch?v=QhTj3Ax98sY

Idempotency is a property of an operation where performing the operation more than once has the same effect as performing it once. For example, setting a variable to 5 is idempotent because setting it twice to 5 has the same effect as setting it once. But incrementing the variable is not idempotent because performing the increment twice results in the variable going up by 2 rather than 1. • Idempotent operations are important in many contexts when we want to perform an operation exactly once. If I visit a website and buy an item, and I hit the big “Pay Place Order” button to trigger the final payment, I would like to be charged exactly once and receive one item. But if I accidentally hit it twice, I might double-charge myself, which is not great. The reason this matters is because ordering and being charged is an non-idempotent operation. If I were doing something else like setting my profile picture, I could hit the “upload” button as many times as I want, knowing that double-setting my profile picture has the same impact as setting it once. That’s because setting your profile picture is idempotent. In the same sense, mashing the walk button at a crosswalk over and over is fine because it’s idempotent, so hitting it more than once has the same impact as hitting it once: it signals to the traffic light that you want to walk. But hitting the ticket button at a ticket dispenser over and over would not be good because it’d dispense a ton of tickets. That’s not idempotent. • Performing an operation exactly once becomes even trickier once we introduce network unreliability. This happens often when communicating between an app on a smartphone and a server, because data coverage can be unreliable at times, and a lot of people perform important transactions from their smartphones, which involves sending a message, like an API call, from the app to the server and receiving a response. In this video, we’ll consider two kinds of network unreliability: that any message between the app and the server can be dropped, meaning lost forever, and that any message can be arbitrarily delayed, meaning it could arrive a minute or even an hour after it’s sent. • Let’s say I hit the “Place order” button on my phone to order something, and in the happy case, the app sends the request to a server for processing, and the server charges me and responds with “OK, transaction processed”. But, what happens when I hit “Place order”, and the app sends the request to the server, but never receives a reply? How does the app know if the payment went through? • Well, there are two possible scenarios: one, that the request was dropped on its way to the server, and the server never heard it. In this case, the payment hasn’t gone through. And the other scenario is that the request made it to the server and the server processed the order, but the response was dropped on the way back to my phone. In this scenario, the payment has gone through. Of these scenarios, the request drops on its way to the server, and the response drops on its way back to me, which one is true? Bad news: there’s no way to know, because they both look the same to my phone: silence. At this point, all I know is that the payment has either not gone through, or has gone through once. We call this situation “at-most-once” because the payment has happened at most one time. But we want to do better. We want our payment to happen exactly once. • We could try improving on this by retrying requests. If we send a request and don’t hear back from the server, we can wait an amount of time, called the timeout length, and send the request again if we don’t hear back. • There are three scenarios here, and as we just discussed, the app doesn’t know which is true. First, if the original request never made it to the server, then retrying is safe. • Second, if the server received our first request, but the response was lost, retrying could cause a double-charge. • Third, maybe the request was delayed instead of dropped. Remember that the network can arbitrarily delay communication between the app and the server, so the request could show up at the server 5 minutes, or even an hour, after we sent it. So we might hit the timeout, retry the request, and then the original request shows up, which could also result in a double-charge. • 00:00 Intro • 00:23 Why Idempotency Is Important • 01:21 Network Unreliability • 01:56 Network Unreliability Example • 02:18 Possible Outcomes At Most Once • 03:06 What If We Retried Failures? • 03:20 Possible Outcomes When Retrying Failures • 03:55 At Least Once • 04:26 Bringing It Back To Idempotency • 05:06 Generating Request IDs • 06:33 Recap • 07:22 Appendix

#############################

New on site