> RPC is always going to be a more reliable approach. Seems like an odd statement. RPC seems considerably less reliable to me since it ties your business logic

> RPC is always going to be a more reliable approach. Seems like an odd statement. RPC seems considerably less reliable to me since it ties your business logic services states' together. > I would much rather an exception be raised immediately and crater the caller Why? The caller might not care. And what if you have a large graph of callers? You're going to end up with a cascade of failures, when really none of them are going to do anything except retry or drop - something that the failing service is capable of making the call to do in most cases. > I have worked in environments that used messaging on a massive scale, Same, and in my experience it was the RPCs that caused the most trouble. I don't think anecdotes are going to be helpful here. > Perhaps you want to make sure all lots that tripped that warning are handled If you want to make sure of something, and then you don't make sure of it, I don't see how that's the fault of a queue. Just... check?