idempotent design seems to bring more control - A program is idempotent if when we run the program multiple times (on the same input), it will have the same effect as if we run it only once. - How I like to think about idempotence is that we have some _desired state_ (the input), and then we have _an actual state_ and the purpose of the program is to _bring the actual state to the desired state_. ## Examples & Further reading - [More control with idempotency](https://marcel.is/more-control-with-idempotency/) - [How to write idempotent Bash scripts · Fatih Arslan](https://arslan.io/2019/07/03/how-to-write-idempotent-bash-scripts/) - [Idempotence Now Prevents Pain Later by Eric Lathrop](https://ericlathrop.com/2021/04/idempotence-now-prevents-pain-later/) - [Design Patterns and Principles That Support Large Scale Systems | by Nir Alfasi](https://medium.com/everything-full-stack/design-patterns-and-principles-that-support-large-scale-systems-f3c9adf89ad) ## some advantages that I have observed - higher control over the logic - higher resiliency against (service) disruptions - easier auditing and bug-fixing when something is not going according to plan, - higher flexibility to change the logic for the desired state later and re-run the whole program from the very beginning, - the dev experience might feel more ergonomic, - idempotent concepts might feel easier to think and reason with (idempotency might be considered to fall into the same bucket of mental models as immutability, and [[declarative style appears easier to reason with once you grasp the nature of it|declarative]]) ## some disadvatanges - calculating the difference between the desired state and the actual state can take long. - I've encountered this issue when calculating the difference using Postgres cross-joins over two big tables. - We had to optimize the calculation by storing the timestamp of the last execution and then computing the difference using that timestamp