# The Big Little Guide to Message Queues - Sudhir Jonathan Synced: [[2024_02_19]] 11:22 PM Last Highlighted: [[2024_02_17]] ![rw-book-cover](https://images.unsplash.com/photo-1549416096-1030b127970e?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=MXwxMTc3M3wwfDF8c2VhcmNofDI2fHxxdWV1ZXN8ZW58MHx8fA&ixlib=rb-1.2.1&q=80&w=2000) Summary: Message queues are a common way to transfer information between systems. They allow for structured communication between systems and can handle the movement of messages at a controlled speed. Message queues offer benefits such as decoupling and the ability to handle multiple messages at once. There are different delivery guarantees in message queues, including at-least-once, at-most-once, and exactly-once semantics. It is impossible for any messaging system to guarantee exactly-once delivery due to various factors that can go wrong. FIFO queues can provide strict sequential ordering but limit parallel processing. Designing messages for out-of-order delivery and idempotency can make systems more resilient and allow for parallel messaging systems. ## Highlights [[2024_02_17]] [View Highlight](https://read.readwise.io/read/01hpvn565xjz430zkzw6t6k823) > This is the most common delivery mechanism, and it's the simplest to reason about and implement. If I have a message for you, I will read it to you, and keep doing so again and again until you acknowledge it. [[2024_02_17]] [View Highlight](https://read.readwise.io/read/01hpvn5rg0wnfwsqvbg7y8mxdx) > Everyone who builds or uses distributed systems has a point in their lives where they think “how hard can this be?”, and then they either (1) learn why it's impossible, figure out idempotency, and use at-least-once, or (2) they try to build a half-assed “exactly-once” system and sell it for lots of money to those who haven't figured out (1) yet. [[2024_02_17]] [View Highlight](https://read.readwise.io/read/01hpvn4djcmkgw3x4800h9jfh5) > Does that mean that the ordering in parallel queues is completely random? Sometimes, yes, but most often no. [[2024_02_17]] [View Highlight](https://read.readwise.io/read/01hpvn3wcnd1q7333nt2k0kac6) > This is called a *fan-out* problem, where a message from one producer needs to reach many consumers. [[2024_02_17]] [View Highlight](https://read.readwise.io/read/01hpvn3zc31dc45kmz7ym54637) > This is a *fan-in* problem, where the messages from many producers need to reach the same consumer. [[2024_02_17]] [View Highlight](https://read.readwise.io/read/01hpvnbqyv3gabjan8dqfk9cag) > Automatically copying a message from one topic into one or more queues isn't strictly a message queue feature, but it is complementary—most full-featured messaging systems will offer a way to do this. Producers will still continue to put messages into a single place as usual, but this will be a topic, and internally the messages will be copied to multiple queues, each of which will be read by their respective receivers. > In AWS, the service that provides topic based messaging is the Simple Notification Service ([SNS](https://aws.amazon.com/sns/)). Here you create a topic and publish messages into it—the API to publish a message into an SNS topic is very similar to that of publishing a message into an SQS queue, and most producers don't have to care about the difference. SNS then has options available to publish that message into any number of *subscribed* SQS queues (at no extra charge). Each of these subscribed SQS queues would then be processed by their respective receivers.