Messaging patterns

Messaging patterns help in connecting services in a loosely coupled manner. What it means is that services never talk to each other directly. Instead, a service generates and sends a message to a broker (generally a queue) and any other service that is interested in that message can pick it and process it. There is no direct communication between the sender and receiver service. This decouples not only makes services and overall application more reliable, but also more robust and fault tolerant. Receivers can receive and read messages at their own capable speed.

Messaging helps in creating asynchronous patterns. Messaging involves sending messages from one entity to another. These messages are created and forwarded by a sender, stored at durable storage, and finally consumed by recipients.

The top architectural concerns addressed by messaging are the following:

• Durability: Messages are stored in durable storage and the application can read it later after they come up in case of prior failure
• Reliability: Messages help in implementing reliability with design since messages are not lost because they are persisted in disk
• Availability of messages: The messages are available for consumption by applications after restoration of connectivity and prior downtime

Azure provides service bus queues and topics to implement messaging patterns within applications. Storage queue can also be used for the same purpose.

Choosing between Azure service bus queue and storage queue is to decide between how long the message should be stored, size of the message, latency, and cost.

Azure service bus provides support for 256 KB message size, while storage queue provides support for 64 KB message size. Azure service bus can store messages for an unlimited period, while storage queue can store messages for seven days.

The cost and latency are higher in case of service bus queues.

Depending on application requirements and needs the preceding factors should be employed before deciding the best queue.