Asynchronous communication has become an important strategy for modern software systems, particularly in distributed and large-scale applications.
Unlike synchronous communication, where a sender waits for a response before proceeding, asynchronous communication allows processes to continue without waiting. This has a significant impact on the system’s performance, scalability, and resilience.
Some real-world scenarios where async communication shines are as follows:
- An online store where an order placement triggers real-time calls to inventory, payment, and shipping services. If any of these services experience latency or downtime, the order process stalls, leading to poor user experience and lost revenue. Using a message queue, the order service can immediately enqueue messages for inventory, payment, and shipping.
- IoT systems like smart home devices often involve thousands of sensors sending data to central servers. A synchronous approach can overwhelm the server during peak activity, leading to data loss or delayed responses. Message queues allow sensors to send data without waiting for processing.
- In a microservices architecture, tightly coupled services communicating synchronously can create cascading failures. With message queues, services communicate indirectly, reducing dependency and allowing independent scaling.
These are just a few examples. There are several potential scenarios where async communication is important. But what makes async communication possible?
This is where message queues come into the picture.
Arguing Semantics
There’s simply no way to learn about message queues without reading and/or arguing about delivery guarantees and semantics, each message you put into the queue will be delivered:
- at-least once.
- at-most once.
- exactly once.
At-Least Once
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.
At Most Once
This is a pretty rare semantic, used for messages where duplication is so horribly explosive (or the message so utterly unimportant) that we’d prefer not to send the message at all, rather than send it twice. At-most-once once implies that the queuing system will attempt to deliver the message to you once
Exactly Once
This is the holy grail of messaging, and also the fountain of a lot of snake-oil. It implies that every message is guaranteed to be delivered and processed exactly once, no more and no less.
Summary
Message queues act as intermediaries, enabling asynchronous between producers (senders) and consumers (receivers). In this article, we’ll look at understanding how message queues work, the various terminologies involved, and the patterns that can be implemented using them.
References from: https://blog.bytebytego.com
