C.3. Service Broker
I'm creating something of a misnomer here by calling this a different service. You see, the Service Broker is built into the core database service. That said, it really is its own thing, and thus I treat it as though it is a different service.
So then, what is it?
The Service Broker is something of an asynchronous communication service, but it offers functionality that goes beyond notification. Its job is to coordinate messages between different applications. Not all applications are always able to communicate directly. For example, the applications may run at completely different times (not all applications run as services—which is to say, they aren't "always on"). Even if your applications can communicate directly, that doesn't mean that you really want them to. Take the case of an application that is subject to burst usage—say, for example, a company that sells concert tickets. A given concert will have tickets go on sale at a specific time. If it is a popular performer, it is not at all uncommon for a show to sell out thousands of seats in the first few minutes of ticket sales—imagine the load on your system! Now, imagine being able to distribute those requests to a farm of servers that pick up the next ticket request in the queue as they are ready to process the next request.
The Service Broker allows different programs to communicate indirectly—with one application leaving a message for another and then continuing with its own work reasonably assured ...