3 ms·
It triggers my eyebrow when a highly available message queue offers either exactly-once delivery or reliable time sorting. I'm not saying I wouldn't give this
by menacingly 9y ago
It triggers my eyebrow when a highly available message queue offers either exactly-once delivery or reliable time sorting.
I'm not saying I wouldn't give this project a closer look, but I would much rather a product make it painfully obvious what compromises were made to offer its availability.
My instinct is: either you need strict constraints on ordering and delivery, in which case you use rabbit, or you need at-least-once-no-matter-what semantics, in which case you use something else and make your app less fragile.
- meebs 9y agoHey, what would "something else" be in this scenario?
- dkersten 9y agoKafka perhaps?
- menacingly 9y agoUsually it would advertise "at-least-once" somewhere prominently, like SQS, NSQ, etc. It's really hard to be extremely available and to also guarantee there won't be dupes or out-of-order messages. Like databases, someone saying they offer both is usually hiding a trade-off. EDIT: I think here "really hard" is a polite way of saying "impossible"
- markbnj 9y agoPerhaps redis streams http://antirez.com/news/114 http://antirez.com/news/114
- eternalban 9y agoHaven't looked but the ordering has to be per partition. > something else https://www.confluent.io/blog/exactly-once-semantics-are-possible-heres-how-apache-kafka-does-it/ https://www.confluent.io/blog/exactly-once-semantics-are-pos...
- lifeisstillgood 9y agodo you know a good primer on the basics behind all these issues. i can sorta see how i would build a message queue that ordered by time, but lost messages would be a problem and so forth - just to get n idea of the trade offs