I work on a SaaS system which is generally a single-tenant environment. Customers (whom the SaaS instances are for) would like a way to subscribe to events, such as updates of certain data entities. For the most part, it seems like a general Pub/Sub architecture, where our system publishes the message, and the customer would subscribe to those events. They might subscribe multiple times to the same events for different integrations.

Is RabbitMQ a suitable solution to service those needs? It is certainly technically possible, but is it the right approach? Whilst it isn't "public facing" in the traditional sense, it's also not strictly "internal" service-to-service communication.

My understanding is that the customer would need a queue per consumer, and we would probably use a Topic exchange so that we could have custom routing, in case we want to some granular control over what gets into each queue.

We also envisage we will use the same RabbitMQ instance for internal needs, such as where we want to hand-off work to another service, or trigger a process whenever a specific event is triggered.

I've struggled to get a sense of this, based on the various articles I've read, as they primarily focus on the technical aspect, and not from the perspective of SaaS serving a customer. Perhaps because it isn't the right approach - my main concern!

  • Is this a cloud environment? do you have access to services like blob storage (azure), s3 buckets, or kafka? Aug 12, 2023 at 7:19
  • Yes, it is. We can access those products if we want, and use Blob Storage already.
    – Richard
    Aug 14, 2023 at 13:42

1 Answer 1


Rabbit MQ can be used for publishing events.

Event is semantically something published by a service. The service that is publishing the event generally doesn't care about the consumers who act on the events.

To achieve the above, there can be one fanout exchange and multiple queues can be bound to it (one queue per client interested in the event). Read more at here

This design would be simple, the subscribers do not need to keep track of the handled events. The handled events would be removed from the queue. This behavior has one drawback. The older events are not going to be available for subscribers.

If you would like to have all the historical events, then Kafka would work well. Here the client tacks the events handled.

If you find Kafka too complicated to set up, you could perhaps use a blob storage where the producer keeps appending to the blob. The consumers could keep reading it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.