Idempotency – Key Concept

In this video excerpt, the Andrew Rivers delves into the crucial topic of disaster recovery and system robustness, with a particular focus on the concept of idempotency. Through a relatable scenario involving an online purchase, the speaker illustrates the importance of idempotent systems in ensuring operational consistency and preventing duplicate actions. This introduction sets the stage for a detailed discussion on how idempotency plays a vital role in building resilient systems, especially when recovering from failures.

Lately, we’ve been talking about a lot of concepts around disaster recovery and high availability. Today, we’re going to discuss a key concept called idempotency, which is beneficial for disaster recovery but also generally for building robust systems. Now, imagine you’re browsing the web and you find something you want to buy. You go through the checkout, press “Pay,” and it warns, “Don’t press refresh on your browser or you may be charged twice.” That is really bad because what they’re not doing is being idempotent. In a good idempotent system, you can make the same request more than once, but you’ll only be charged for it once. This is really important because sometimes, when things have gone wrong, you need to replay everything again, and you don’t quite know whether it’s finished or not. Because if you fail over from one site to another, if you can just replay that work and if it’s already completed once, it’ll just confirm, “Yeah, I’m all good with that. We don’t have to do it again.” Then it makes the whole process of failing over a lot easier because you can just replay everything else and everything else takes care of itself.

And you do that by having an idempotent system. The key thing there is all about managing identifiers. Let’s say you’ve got a process that calls another system to do stuff, which could involve taking payment, and that fundamentally changes the state in here. What you’ve got to do is, when you kick off this process, you need to create an identifier in there to say, “Do stuff, and here’s my identifier.” So when System A registers that, it’s like, “Good, I’ve done that stuff, but I’ve also got an identifier with it.” So then when something goes wrong, maybe, and you have to retry, when you come around your retry loop and say, “I’ll do that stuff again. Here’s my original identifier,” System A will just confirm, “Yeah, all good. Got that.” Because you’ve sent the request twice. But because those are tied together by the same identifier, you’ve done the thing once, which means if something happened, you’ve just got to replay, and everything else takes care of itself. That’s the key concept in idempotency. So bear that in mind as we go through the rest of our series on disaster recovery.

Chat to us about your Integration journey

Get in touch

Share this post