I strongly believe that a key aspect of software engineering is applying proven architectural patterns. Lately I have wanted to write about some of these patterns which address many engineering concerns in any enterprise scale software. One such pattern is Asynchronous processing through message queues.
There is ton of information available on internet on the usage of message queues. I have been in many discussions about software design where the topic of message queue would come up and someone would say - "Why should we use message queues?". Here is my attempt to address this question.
Asynchronous Interaction: Many times the messages or events don't need to be processed immediately in real time and can be delayed. It means that critical processing can be done in real time and non-critical processing can be delayed. This could potentially help in reducing response time for the synchronous processing. Message queues enable the asynchronous processing by allowing messages to be put into a queue which can be processed later. Notifications such as sending e-mails is one such example.
Decoupled Architecture: Decoupled software components allow each component to evolve and scale without impacting other components. Message queues form an intermediary between the two components which share which agree to a data (message type) based interface.
Reliability through Guaranteed Delivery: Messaging infrastructure provides guaranteed delivery of messages. In the event of failures, messages are not lost and can be recovered and reprocessed.
Scalability: Message queues decouple the producer and consumer components. This allows scaling up the rates at which messages are added to the queue or processed. By adding new processes, the system can scale without requiring additional code changes.
Resiliency: Message queues provides isolation between various components. This means that the entire system doesn't go down if some parts fail. Systems can be designed such that the critical components can continue processing in the event of failures in the other parts of the system.
Throttling: In order to protect the system from getting overloaded, it is necessary to throttle the request processing. Typically when a throttle limit is reached, the application denies request processing. This may not be acceptable in a HA system. In such cases, requests can be queued when a throttle limit is reached. The queued requests can then be processed when the load on the system is reduced.
Throughput: Message queues allows possibility of concurrent execution of the processes. This means that the system throughput can be tweaked through addition of processes. However there is some tension between throughput and reliability. In order to increase message throughput, it is recommended to turn off message persistence.
Ordering: Driven by the business needs, many applications require message to processed in a sequential manner. Most message brokers allow message ordering through server side or client side mechanisms.
Event Driven Processing: Messaging frameworks provides a mechanism to implement event driven architectures. Such systems typically consist of event emitters (agents) and event consumers (sinks). Messaging frameworks naturally fit into this model.
This is not a complete list but some of the key benefits of message based solutions.
Reliability through Guaranteed Delivery: Messaging infrastructure provides guaranteed delivery of messages. In the event of failures, messages are not lost and can be recovered and reprocessed.
Scalability: Message queues decouple the producer and consumer components. This allows scaling up the rates at which messages are added to the queue or processed. By adding new processes, the system can scale without requiring additional code changes.
Resiliency: Message queues provides isolation between various components. This means that the entire system doesn't go down if some parts fail. Systems can be designed such that the critical components can continue processing in the event of failures in the other parts of the system.
Throttling: In order to protect the system from getting overloaded, it is necessary to throttle the request processing. Typically when a throttle limit is reached, the application denies request processing. This may not be acceptable in a HA system. In such cases, requests can be queued when a throttle limit is reached. The queued requests can then be processed when the load on the system is reduced.
Throughput: Message queues allows possibility of concurrent execution of the processes. This means that the system throughput can be tweaked through addition of processes. However there is some tension between throughput and reliability. In order to increase message throughput, it is recommended to turn off message persistence.
Ordering: Driven by the business needs, many applications require message to processed in a sequential manner. Most message brokers allow message ordering through server side or client side mechanisms.
Event Driven Processing: Messaging frameworks provides a mechanism to implement event driven architectures. Such systems typically consist of event emitters (agents) and event consumers (sinks). Messaging frameworks naturally fit into this model.
This is not a complete list but some of the key benefits of message based solutions.
