The title of this article is a play on words: idempotence is not impotence. The article sketches what can go wrong with messages used to coordinate work done in a distributed computing environment. Such messages may be broken into pieces, arrive out of order, or be lost. Remote servers can crash and be restarted, possibly losing pieces of earlier messages. The same remote server may not be selected to receive each message in a set. Remote servers may subcontract work to a third remote server. If servers resend messages to recover from situations like these, the messages should be idempotent; that is, sending multiple copies of a message should produce the same end result as if just one copy were sent.

The term “plumbing” is used to describe the underlying messaging system, and well-made plumbing should be able to isolate the distributed computing application developer from having to worry about situations like these. However, such plumbing is not on the horizon and may never happen, so distributed application developers should apply the principles described in this paper to avoid these kinds of messaging failures.