Why Idempotent is very critical in Backend Applications

Why Idempotent is very critical in Backend Applications

Today, I am here discussing "Exactly-once delivery". Now you puzzled by that sentence what I am trying to say that thing is one of the hard problems in the Distributed System and her solution is Idempotency.

Idempotency is something you might not see every day, but it is an important concept, especially when you are making payments.

As a developer, you are always wanting things to go smoothly, but in the world of REST APIs, that isn’t always the case. Client failures, networking errors, or just poorly written code can all spell trouble for an API call (and your end-user experience). Luckily, idempotency is here to help! It can be a little confusing at first, but once you have a handle on it, you’ll see that it is an important aspect of designing and using mission-critical systems.

Idempotency is an often-used term in computer science. It's meaning to some might not be known, to others, it's very well known. The explanation for idempotency is:

The property of some operations such that no matter how many times you execute then, you achieve the same result.

In the context of a developer working with REST APIs, your application is sending requests and getting back responses with some other service on the internet. When that API is an idempotent guarantee that when you send an identical request you will always get an identical response. What do I mean by identical? The headers, body, authorization, everything needs to be exactly the same.

Not all REST APIs use idempotency, most of the time it is only necessary for requests that influence the state of something, or you really don’t want to accidentally run twice. For many APIs, this is limited to POST or PUT requests, whereas most “state neutral” requests do not add the complexity to their interfaces.

Let's understand that with a simple example:

When Client/End-User wants some information usually the GET method is used. Way change user mistakenly requests 10 times or even millions of times then that information doesn't change in meanwhile.

get_resquest.png

But, When the user used POST request quite several times, then might that identical requests is stored multiple times in the database.

post_request.png

Originally we as a Developer does not want that going on, which lead to a fatal mistake accidentally. So in my point of view, there is two way we can avoid that error:

  1. Suppose we are going to make order in amazon site to buy hard drive in that case amazon put some param in API of order like:

    POST /order/:userId/:productId/

    In that case, the server only checks product and user already make an order or not if not make entries in the database. If the next request is the same then the server regret request and then not make two orders of the same product.

post_param.png

  1. Some of the developers using hashing. They hash the body of requests and check hash are present in the database or not, if not then feed in the database.

In my point of understanding view, these are an easy approach to deal with that kind mistake, and maybe more solutions are available than these two.

Essentially, idempotency is the mathematical way of saying “one can apply a certain operation on something many times, without changing the result of the operation after the first time the operation is applied”.

If you want to learn more about this then follows these link: