Welcome to the fascinating world of programming! There are so many important concepts to grasp in order to create efficient and reliable systems. One such vital concept is idempotency, which is the property of an operation or function that yields the same result when applied multiple times as it does when applied only once. This seemingly simple concept has significant implications for building distributed systems. In this article, we’ll delve into what idempotency is, why it’s crucial, and how to achieve it. Whether you’re a beginner or an experienced developer, understanding idempotency is an essential skill that will help you build more robust and reliable systems.
Why Should Programmers Care About It?
Idempotency is a concept that is important for programmers to understand, especially those working on building distributed systems. In simple terms, idempotency means that if you perform an operation multiple times, the end result should be the same as if you had only performed it once.
In other words, an idempotent operation is one that can be repeated multiple times without causing any additional side effects. This is important in distributed systems because messages can sometimes be lost or duplicated due to network issues, and if an operation is not idempotent, repeating it can cause unintended consequences.
Let’s say you’re building an API for processing payments. If you design the API with idempotency in mind, you can ensure that even if the same payment request is sent multiple times due to network issues, it will only be processed once. This can prevent double-charging customers, which can lead to trust issues and lost revenue.
The “same” request hitting your API should not modify your state for the second time. (Milan Jovanović – Tweet)
Topkapi Palace MuseumA little more Idempotency APIs
We use many methods to design our systems to tolerate and reduce the probability of failure and avoid turning a small percentage of failures into a complete outage. Some of these are especially vital in distributed systems.
Microservices example
Let’s say we have a food ordering application, and to keep our application simple, let’s say we have two basic services, Shipping and Order. When one of our customers places an order, first the order is created, and then shipping instructions are created. If all transactions are successful, it sends a notification to the client. Even in this simple scenario, many failures can occur. These failures can come from a variety of factors. They include servers, networks, load balancers, software, operating systems, or even mistakes from system operators. For example, even if the order and shipping service do their job properly, what happens if the customer cannot receive a response due to network latency while returning the response? Of course, the first thing that comes to mind for such cases is to use patterns such as timeout, retry, and backoff. But what if we try the service call again in this scenario?
