Messaging Systems

How to Make Your Messaging System Reliable and Keep Your Support Engineers Happy

When a messaging system lies at the heart of your application architecture you need to make it easy to respond to message processing failures. The more queues you have the more important a coherent incident response capability is. Unfortunately, it is all too common to see a chaotic policy or no policy at all for handling messages that cannot be processed successfully. Messages get delayed or lost on a regular basis and no-one is even sure how many.

The normal approach is to create a dead letter queue on a queue by queue basis and send messages there that cannot be processed. But what do you do from there? In this post we'll be looking at a message lifecycle baked into the messaging architecture that can solve this problem.

RabbitMq Delayed Retry Approaches (That Work)

Problem: You want either a fixed or exponential back-off with your retries. There are a few ways of making this work and all use the dead letter exchange functionality. The best I have seen is NServiceBus and unfortunately there are a few blog posts out there with just plain bad advice. In this post we'll look at the bad advice, some per application solutions and also the NServiceBus method which works as a central retry infrastructure for an entire virtual host.

Reliability - Custom Retries - NServiceBus with RabbitMq Part 6

NServiceBus provides really nice customisation features for your recoverability functionality. We already saw how you can customise the immediate and delayed retries. In this post we'll look at implementing our own custom policy which allows us to make decisions based on the exceptions that are thrown in the message handlers.

The NServiceBus documentation on customising your recoverability policy is well explained and so I recommend you read their documentation first. 

Custom Topology - NServiceBus with RabbitMq Part 4

In this post we'll implement a class that inherits from IRoutingTopology and that plugs into NServiceBus to create a custom routing topology. There is also the IDeclareQueues interface that we could also implement but I doubt I would ever need to. NServiceBus creates a bunch of queues in addition to the main endpoint queue, for things like retries and timeouts. I don't want to mess with these as they are important for how NServiceBus gives us the functionality that it does. So in this post we'll just be customising the RabbitMq artefacts beyond the immediate endpoint queues.

Custom Direct Topology - NServiceBus with RabbitMq Part 3

In this post we'll look at how we can customise the Direct Routing Topology. The source code is on Github.

Create a new solution folder and called it RabbitMqTransportCustomDirectTopology and add the four projects named as follows: Rabbit.Custom.ClientUI, Rabbit.Custom.Sales, Rabbit.Custom.Billing and Rabbit.Custom.Shipping.

Default Topologies - NServiceBus with RabbitMq Part 1

NServiceBus has excellent features and while not free can lower the total cost of ownership if you have a large messaging based platform. In this first part of this series on NServiceBus and the RabbitMqTransport, we'll look at the default RabbitMq topologies generated by NServiceBus. All source code is on Github.

How to Deal with Unroutable Messages - RabbitMq Publishing Part 3

In Part 2 we saw how we can detect that a message was unroutable, in this part we'll look at how you can deal with that situation.

RabbitMq offers us the Alternative Exchange for this purpose. When we declare an exchange we can specify the name of an alternative exchange that messages will be forwarded to when a message is unroutable. We just need to make sure that we bind a queue to that exchange that accepts all messages.

Sending Messages in Bulk and Tracking Delivery Status - RabbitMq Publishing Part 2

This is a console application that will create an exchange and queue for you, and allow you to send messages in bulk with message delivery status tracking.

First we'll look at the following design decision you will likely encounter when performing reliable bulk send operations.

Performance/Duplication Trade-Off

When sending messages in a bulk operation you want both decent performance and want best effort reliability - you have two conflicting concerns. When I say reliability I meant that you need every message to get delivered and you ideally want to avoid message duplication.