Service Broker in a nutshell

Lately I was looking into different Queuing Technologies to choose the best fit for the upcoming project. In that post I just want to summarize my finding.

I was already familiar with Azure Service Bus and Rabbit MQ. But we didn’t need advanced routing capabilities they both provide, hence I decided to look into alternative solutions. By the way here’s a very nice Service Bus for Windows Server & RabbitMQ comparison.

We were already using MS SQL Server to persist the data. So using Service Broker was an appealing choice from the very beginning.


  • Very easy to backup/restore
  • Sequential Delivery & Related Messages Locking (plus it allows to access internal Sequence ID & Sequence Number)


  • To en-queue message you should have a conversation first. It means you en-queue message into one queue and listen for messages to appear on another queue
  • Index fragmentation then Dealing with Large Queues

Alternative solution is to use tables as queues. The main disadvantage of it is the lack of Activation. Which means you will have to Pull messages from the queue. While Service Broker, Rabbit MQ and others provide Push mechanism to notify listeners about newly added items.

I highly recommend you to read in-death book on Service Broker Pro SQL Server 2008 Service Broker  so you will know better in which cases you can leverage Service Broker capabilities.