Introduction
Configuration
Language Support
AMQP 0-9-1 Overview
- The AMQP Protocol
- Connections & Channels
- Queues
- Messages
- Bindings
- Exchanges
- Vhost
- Publishers and Consumers
More Exchange Types
More Consumer Features
Queue Deep-dive
Other Features
Reliable Message Delivery
High Availability and Backup
Monitoring
Management HTTP API
Tutorials
Networking
LavinMQ CLI
Topic exchange
Previous Tutorial: Direct exchanges
In the previous tutorial we implemented a notification system where users could customize their notification settings to specify exactly what channels out of the three they’d like to receive notifications from.
In this tutorial we will even take things a step further - users can customize their notification settings in a more granular way.
Note: This tutorial will only cover the theory of extending our previously implemented notification system. For your capstone project, you will implement this extended notification system all by yourself in your favourite programming language.
Use case: An extended notfication system
Let’s extend our previously implemented notification system. The number of channels still hasn’t changed:
- HR
- Marketing
- And Support
In addition to what we’ve done in the previous tutorial, here, users can also customize their notification settings to only receive notifications for very specific activities within the channel they’re interested in. To keep things simple, we are only going to have two categories of activities: new_messages and new_member_joined.
Even though in reality we are likely to have a lot more scenarios, for brevity’s sake, here, let’s assume that we are going to have these categories of users:
- Persons that would want to receive notifications for messages in the marketing channel
- Persons interested in notifications for when new members join the support channel
- Persons interested in notifications for new messages in all the channels
- And the last set of persons that would want to receive notifications for everything.
To do that we will: - Create four queues: marketing_messages, support_new_members, all_messages, and all_notifications - marketing_messages: to only receives notification for new messages in the marketing channel - support_new_members: to only receive notfications for when new members join the support channel - all_messages: to receive notifications for new messages across all channels - all_notifications: to receive notifications for everything across all channels - Create a topic exchange named slack_notifications - Bind the four queues to the slack_notifications topic exchange using the respective binding keys: notifications.marketing.messages, notifications.support.new_member_joined, notifications.*.messages and notifications.#
The image below gives a visual representation of the flow of messages from the slack_notifications topic exchange to the four queues we mentioned earlier. The setup will have two messages A and B with the routing keys: notifications.marketing.messages, notifications.support.new_member_joined respectively
Now that we fully understand our use-case and most of the implementation details, let’s proceed to the capstone project.
Capstone project
-
Challenge: Given the information above, create a producer application that will send messages to the queues you declared via a topic exchange and a consumer application that will receive those messages and process them.
-
Theoretical Reflection: How would you modify the existing system to handle this new requirement while still maintaining the functionality of the fanout exchange for other notifications?
-
Hints:
- Your producer application shouldn’t change much - a couple of changes you’d need:
- Switch to using a topic exchange
- You then declare four new set of queues - enough information has been provided on this in the description of the use-case
- Bind your queues to the exchange and publish four messages
- On the consuming side, you need to bind four different consumers to the four queues. A couple of things to reflect on:
- Do you want to create four separate consumer scripts - if you do this then the only difference between the scripts would be the queue each consumer subscribes to
- Do you want to run a single consumer script with different arguments - We recommend this, but keep in mind that finding a neat way to do this might be tricky, but it’s totally doable.
- Your producer application shouldn’t change much - a couple of changes you’d need:
What’s next?
- Next Tutorial: AMQP over websocket with LavinMQ
- Previous Tutorial: Direct exchanges
Ready to take the next steps? Here are some things you should keep in mind:
Managed LavinMQ instance on CloudAMQP
LavinMQ has been built with performance and ease of use in mind - we've benchmarked a throughput of about 1,000,000 messages/sec. You can try LavinMQ without any installation hassle by creating a free instance on CloudAMQP. Signing up is a breeze.
Help and feedback
We welcome your feedback and are eager to address any questions you may have about this piece or using LavinMQ. Join our Slack channel to connect with us directly. You can also find LavinMQ on GitHub.