The more I work with systems exchanging messages among them, the more I am aware of idempotency
.
Formally speaking, in mathematics, an idempotent function has the same effect no mater how many times it is applied. Think about a remote to lock/unlock a car, most remotes will just lock the doors no matter how many times you press the lock switch. In mathematical notation:
f(x)=f(f(x))
Why is it so important? Well, if you have a set of uncoupled systems, you can experiment partitions or other problems that prevent messages from being successfully processed. If this is the case the first thing you need is the ability to retry sending the message not warring about a possible duplicate effect on the world.
How to implement idempotency
There are two options to do idempotency:
- store state at the server so that it recognises a duplicate request and just ignores it, usually it is achieved storing the processed messages IDs; or
- make the algorithms idempotent, imagine something like when the message encodes an intention rather then the way to do something. One example would be in a game have the instruction
grab sward
, no matter the amount of times it is processed the effect would be the same.
Final remarks
I strongly support idempotent code, from the start, even if right now you do not figure out the benefits. I always expect idempotency to emerge as an essential way to avoid expensive tasks to avoid unintended duplicates.