Using Queues to improve performance and reliability

Enterprise Systems typically involve two or more applications that collaborate with each other to run a business process. One of the ways that participants of an Enterprise System can share information is queuing. Logically speaking, queues are a system resource where applications in an Enterprise System can place messages for each other. Microsoft Message Queuing (MSMQ) is an example of such a queue.

Message queues provide a repository for inter-application messages and ensure guaranteed delivery of messages. In MSMQ, a queue may be defined as a transactional queue ensuring that the messages are enqueued, and hence dequeued and delivered, in the original order. Furthermore, a transactional queue persists each message received to ensure guaranteed delivery in case of a system crash.

Queues are useful in many Enterprise System scenarios. These scenarios have one thing in common: one application places a message in the queue and another application picks up the message from queue and acts on it. This allows us to distribute work among applications in an Enterprise System. Queues can also improve throughput of an Enterprise System.

Let's consider a stock order processing system that receives a stock order from client applications through a web service call to an endpoint it hosts. The orders must be processed in the order they are received and must not be lost. During peak trading hours of trading, it is likely that the stock order processing system will be receiving orders at a much higher speed than it can process them. In a monolithic, single-threaded stock order processing system, the throughput of the stock ordering system is constrained by the speed at which it can process the orders. Granted to improve performance we can spin two threads: one to receive orders and the other to process the order. But to ensure guaranteed delivery and in-order processing of stock orders received we will have to cook up our own scheme.

Now consider how we can design the stock order processing system more elegantly using queues. Our System will have three components:

1. Transactional Queue
2. Listener Application
3. Order Processing Application

Transactional Queue

A transactional queue can be created using MSMQ.

Listener Application

The job of the listener application is to simply host the endpoint for the receiving the stock order requests and to enqueue these requests as messages into the Transactional Queue.

Order Processing Application

The job of the Order Processing Application is to dequeue a message from the Transactional Queue and to act on it (i.e. to route stock orders to an external trading system).

Some of the benefits of this queue-based design are follows:

1. Stock orders delivered guaranteed because of the Transaction Queue
2. Stock orders are processed in the order they are received because of the Transaction Queue
3. The Listener Application continues to enqueue Stock Order messages even if the Order Processing Application goes down or can't keep up with the rate at which the stock orders are being received
4. We are able to scale Order Processing Application up (more powerful machine) or out (more machines) to improve throughput of the stock order processing system