This may be tongue-and-cheek, but it is not true. That is a great example of a scenario where it is okay to lose messages. The consequences are extremely low if one a billion people is not notified that their food is ready.
This may be tongue-and-cheek, but it is not true. That is a great example of a scenario where it is okay to lose messages. The consequences are extremely low if one a billion people is not notified that their food is ready.
It's not, if a client is in trail with your service and they miss a message you risk losing that client. It's only "Okay" to not deliver on non-client facing services. Anything else is an unmeasurable risk
And that kind of absolutism in technology is the source of a common failure to meaningfully deal with failure modes of your technology.
Losing one in a billion messages telling someone their food is ready can be offset by $100 in marketing budget to buy that person a very nice meal in compensation. We know how to deal with hospitality failures like that, it’s not actually complicated.
Spending the effort to reduce the failure below that is not worth the cost, which is certainly more than $100. There’s almost certainly better usages for those developer resources.
I disagree. The ability to handle data loss comes from the nature of the data, not whether it is client-facing or not. Banking transactions can almost never handle message loss, whether it is client-facing or not. On the other hand, a meal notification service could drop one or two messages and still work properly.