Request: include info about when/why to choose disque vs. streams

[Deimos]

With streams being added in Redis 5, it seems like they include support for a lot of the same capabilities as disque is offering, especially through consumer groups. It would be nice to have a section in the documentation explaining what cases or needs might make you want to choose disque over streams, or vice versa.

[zachmccormick]

Hmm... these are fundamentally different things, though.

Disque is a distributed message (job) broker that aims for exactly-once execution of jobs but can be configured for at-least-once and at-most-once execution guarantees. It also requires clustering + supports seamless addition/removal of nodes, replication factors across those nodes, etc.

Streams is a data type that roughly emulates Kafka's multi-consumer message broker model. Instead of aiming for exactly-once execution of jobs, Streams (and similarly Kafka), exposes a "stream" of messages that can be read by multiple consumers and may persist long after the first (or second or third) consumer consumes the message. Streams doesn't require clustering or anything since it's just a data type.

[jheld]

With consumer groups though it seems that it becomes very close (semantically equivalent) to a message queue. And since streams are more similar to this world than are general redis lists, it appears to be a good mapping, with the requirement of groups in place.

Is this incorrect?

As far as streams vs disque, doesn't mean one is better or worse so much as different systems (and data types at that), which can be chosen based on requirements. Disque sounds very cool! But streams might be easier to go to production whilst disque used in r & d and then production.