From time to time people implement something that they want to use in a fire-and-forget fashion. Typically it is some non-critical service you want to notify. Sadly most people get this wrong since they don't understand what fire-and-forget means and instead fire blindly.
Arguing for better fire-and-forget behavior I've typically relied on my own experience in software development but when I started to write this I realized using a military analogy might be a better way to explain this.
So what I see people doing most of the time is to make this fire-and-forget operation in such a fashion that they don't care if it succeeds or fail. After all it is fire-and-forget is the argument. Some people add some logging but it pretty much ends there. This however is like if an aircraft pilot would pull the trigger to fire a missile and then don't care if the missile was fired or not.
Because the pilot cares a lot about the fire part! If fire fails he will act differently than if the missile was launched. That is, in proper use of fire-and-forget you care a lot about what happens in the fire stage and only once you know that is good you forget.
Back to software. If for example you need to notify another service you should care about if you could actually make that call or not. Can you create the proper objects, can you resolve DNS, can you deliver in a reasonable time. You might even care about the response (did the missile hit the target or not). However you do not care about what happens to the data sent.
Because in my experience a lot of so called fire-and-forget operations are not operations you don't care about. You care a lot about being able to do them. It is only the result that you don't care about.
What fire and forget should mean is write to a queue, guarantee that it was written and do something if the write to the queue fails (queue server is offline, this host is offline).
ReplyDeleteSomething that's a really neat solution for on premise or even just full stack hosting as opposed to PAAS is using MSMQ for this. Just write to a local MSMQ in fire & forget fashion. Then that MSMQ can be configured to sync up with the real server at whatever time is convenient for it. I don't know what other queuing technologies provide a similar experience.