[menacingly]

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.

[eternalban]

Haven't looked but the ordering has to be per partition.

> something else

https://www.confluent.io/blog/exactly-once-semantics-are-pos...

[meebs]

Hey, what would "something else" be in this scenario?

[menacingly]

Usually 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]

Perhaps redis streams http://antirez.com/news/114

[dkersten]

Kafka perhaps?

[lifeisstillgood]

do 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