As part of an ongoing series, we are discussing design principles that influence how ready our code is for distributed computing in the cloud, as well as for multi-core utilization. 

Today we'll talk about idempotence…today we'll talk about idempotence…today we'll talk about idempotence…. Ya, all this and cheap humor too. If you don't get the lame humor, no problem, just read on.... :-)

Idempotence

If code is atomic and stateless (as we discussed in part 2 and part 3) it may take on other attributes like idempotence. Idempotence says I can execute the same method repeatedly and get the same outcome without adversely affecting anything else, like state.

Wikipedia defines idempotence in computing thus:

"In computer science, the term idempotent is used to describe methods or subroutine calls that can safely be called multiple times, as invoking the procedure a single time or multiple times results in the system maintaining the same state; i.e., after the method call all variables have the same value as they did before.

"Example: Looking up some customer's name and address in a database are typically idempotent, since this will not cause the database to change. Placing an order for a car for the customer is not idempotent, since running the method/call several times will lead to several orders being placed, and therefore the state of the database being changed to reflect this.

"In Event Stream Processing, idempotence refers to the ability of a system to produce the same outcome, even if an event or message is received more than once."

Idempotence in a method or function is not always possible, while some logic lends itself naturally to idempotence. Other logic may require safeguards in its design to assure safe repeatability.

When idempotence is possible, extreme flexibility is gained for executing that code across a distributed environment like the cloud. By their natures, some distributed environments expect failure and are designed to work around it. Consider how the internet routes around failure. If I request a web page through my browser, and the request fails due to a backhoe in Des Moines, and I hit reload, my second request will likely take a different route to get the page. Most likely, I could request that page repeatedly and not affect anything except maybe irritating the web master. That’s idempotence in action in a distributed environment where failure happens, and the environment deals with it.

Benefits

Many of the arguments for the value of idempotence are the same as those we've previously discussed for atomic, cohesive, and stateless code running in distributed environments and multi-threaded, multi-core designs. So instead of rehash those discussions, I'll just summarize here.

Availability and load-balancing like idempotent code's repeatable and non-destructive nature. I can run the code on any thread or any node and not worry about side effects.

Reliability in a distributed computing environment like the cloud sometimes means that an execution step may be interrupted by hardware failure. In that event, the distributed environment may decide to repeat the execution step elsewhere. The repeatability of idempotent code is ideal in these circumstances because the method call can be repeated without worry and without dependencies.

Next time in part four, we'll conclude this section by talking about the attribute of parallelizability.