When it comes to building distributed systems, one of the most important patterns is the message broker. But what’s a message broker?

A message broker is an architectural pattern for message validation, message transformation and message routing. It mediates communication amongst applications, minimizing the mutual awareness that applications should have of each other in order to be able to exchange messages, effectively implementing decoupling.

The practical utility of this construct has been proven in many distributed systems over the years.  Within the context of Windows Azure, this pattern is extremely useful for posting messages from within your Web Role implementation to perform some asynchronous work at a later time. Often, this is done to keep the user interface responsive. Other times, this is used just to delay some processing to another time.

Message queues are a first-class citizen within the Azure world.   A single queue message can be up to 64KB in size and a queue can contain up to a million messages. The contents can be anything that fits within that limit, including serialized objects and/or a simple message. (In a future blog post, we’ll discuss the implementation of passing messages between the roles and more details of utilizing Windows Azure message queues.)

A simple but easy-to-understand example of this pattern is sending notification emails upon a key event to a user interacting with your website.

Let’s imagine that a user has just placed an order on your e-commerce site. We want to send the user an email thanking them for their order but we don’t want this operation to slow down their actual shopping cart experience. In this case, a small message would be quickly written to a queue from the Web Role and the user’s web experience will continue unimpeded. A Worker Role instance would monitor the queue for a unit of work (a message) and fulfill the ultimate goal of sending the user a thank-you email. The message would then be removed from the queue. Windows Azure manages the queue so that the message is only available to one Worker Role instance at a time.

As you can see, this pattern effectively creates complete independence between the Web Role and the Worker Role as long as the agreement/interface of the message is maintained.  This pattern is an effective tool in building flexible loosely-coupled systems in Windows Azure.