4 ms·
Idemopotency is up there with immutability, queues & purity for making the life of the software architect bearable. This article glances off a really interesti
by CraigJPerry 5y ago
Idemopotency is up there with immutability, queues & purity for making the life of the software architect bearable.
This article glances off a really interesting related problem - the choice between “at most once”, “at least once” and “exactly once” events.
If the process is due to send an alert mail, but the process (or the server or whatever) dies just after the mail is sent but before the status is updated in the system’s state.
- samhw 5y ago> This article glances off a really interesting related problem - the choice between “at most once”, “at least once” and “exactly once” events. Yeah, I'm not a distributed systems expert, but I think this is one of the foundational problems of distributed systems. And that exactly-once delivery is considered to be impossible over a lossy channel. (That excludes abstractions used to create lossless channels over a lossy channel, such as TCP.) Hence the choice between at-most-once and at-least-once delivery, of which I think most of us choose at-least-once.
- mwint 5y agoWhat do you mean by purity here?
- CraigJPerry 5y agoJust being conscious of side effects really. From an architecture point of view, maybe you’d like to change the space vs. time tradeoff for a component (maybe apply memoization) in response to a change of business need but that can be nasty when the component itself knows how to go lookup business date by itself or how to send a notification etc.