Queue Anti-patterns (an argument in DMs)

gistfile1.txt

I can make a case that queues only do what people want if you don’t consider failure cases. 

Qs are empty (normal) or full (fail). Normally things are processed quickly. Failure case processing time is unbounded (or “too long”). 

Solution is always “dump the Q”.  Which means you do care about how long it takes to process items. So you want the queue to always be empty

Which means you only want a non-failing Q. 

So why not admit it, use in-proc buffers, run enough servers to handle load? Reject work up front instead of dropping oldest items w/…

“flush the queues!”

My broader point is: it's really silly to say that you can't come up with some rules of thumb for the use of any particular technique. Every technology has its use; it's just not useful for every case.

Rules of thumb are a poor substitute for understanding your system and the trade offs you are making. Rules of thumb are important, no doubt, when you are dealing with very complex systems that cannot be comprehended easily (your super scalar processor and its memory hierarchy!), but I don't think this holds for design questions involving distributed systems and queues.