# Disque: A Message Broker Designed for Reliable Message Delivery

DevFeed: [Disque: A Message Broker Designed for Reliable Message Delivery](<https://devfeed.tech/articles/adventures-in-message-queues-20679.md>)

Original publisher: [Read original article](<http://antirez.com/news/88>)

Published: 2015-03-15T22:32:15Z

Content type: article

Language: en

Sources: [Antirez](<https://devfeed.tech/sources/antirez.md>)

Topics: [Redis](<https://devfeed.tech/topics/redis.md>)

Tags: [blog](<https://devfeed.tech/tags/blog.md>), [broker](<https://devfeed.tech/tags/broker.md>), [message-queue](<https://devfeed.tech/tags/message-queue.md>), [queue](<https://devfeed.tech/tags/queue.md>), [redis](<https://devfeed.tech/tags/redis.md>)

## AI overview

The article introduces Disque, an in-development message broker, and explains why developers often use Redis as a message queue. It discusses the differences between Redis data structures and immutable messages, along with at-most-once and at-least-once delivery semantics.

## Source excerpt

EDIT: In case you missed it, Disque source code is now available at http://github.com/antirez/disque It is a few months that I spend ~ 15-20% of my time, mostly hours stolen to nights and weekends, working to a new system. It's a message broker and it's called Disque. I've an implementation of 80% of what was in the original specification, but still I don't feel like it's ready to be released. Since I can't ship, I'll at least blog... so that's the story of how it started and a few details about what it is. ~ First steps ~ Many developers use Redis as a message queue, often wrappered via some library abstracting away Redis low level primitives, other times directly building a simple, ad-hoc queue, using the Redis raw API. This use case is covered mainly using blocking list operations, and list push operations. Redis apparently is at the same time the best and the worst system to use like that. It's good because it is fast, easy to inspect, deploy and use, and in many environments it was already one piece of the infrastructure. However it has disadvantages because Redis mutable data structures are very different than immutable messages. Redis HA / Cluster tradeoffs are totally biased towards large mutable values, but the same tradeoffs are not the best ones to deal with messages. One thing that is important to guarantee for a message broker is that a message is delivered either at least one time, or at most one time. In short given that to guarantee an exact single delivery of a message (where for delivery we intent a message that was received *and* processed by a worker) is practically impossible, the choices are that the message broker is able to guarantee either 0 or 1 deliveries, or 1 to infinite deliveries. This is often referred as at-most-once semantics, and at-least-once semantics. There are use cases for the first, but the most interesting and practical semantics is the latter, that is, to guarantee that a message is delivered at least one time, and deliver mu