C# RabbitMQ Design Approach

Question

I am just getting started with RabbitMQ, because on a website I am working on we want to de-couple some of the resource intensive tasks such as sending emails, generating PDF's etc.

I have started by following the very simple C# "Hello world" tutorial on the RabbitMQ website ( https://www.rabbitmq.com/tutorials/tutorial-one-dotnet.html ). This was useful to get a very brief understanding of how RabbitMQ hangs together, but it has left me with a number of questions that genuinely and surprisingly I can't find answers to online....

1. The "Hello world" example sends a basic string. In my example of sending emails, would my Publisher send all the data needed to send the email ie recipient, subject etc, perhaps in JSon format?
2. How typically would you structure a consumer to execute a method to DoSomething? Ideally, I would like it to be fluent so that if a message is of a particular type the Consumer executes method SendEmail(), or if the message is of a different type it executes the method GeneratePDF() and so on....
3. I have a Publisher and a Consumer, however I have a number of different tasks that I want the Consumer to process ie send emails or generate PDFS. Should i have multiple consumers ie one for each type of task, or, multiple queue's (again one for each task)?

These are some of the basic questions I have that currently are preventing me from seeing how RabbitMQ is used in real-world scenario. Any help would be greatly appreciated.

Answer 1

With messaging, typically you send small-ish packets of data (like simple JSON objects) in the same manner you would as though you were defining an http-based API. The function definitions and input/output specifications can be identical - think of messaging as just a different transport mechanism.

For questions 2-3, yes, you want to set up multiple queues with multiple consumer types. Each consumer type would subscribe to exactly one queue whose messages are intended only for that consumer. Use routing logic on the publisher to determine which queue the messages end up in.