On this page
What the curriculum covers, in one table
The core curriculum is five instructor-led sessions drawn from eleven modules. Platform and SRE teams take clustering, Khepri and partitions, queue types, memory and flow control, monitoring and security. Application developers take the messaging model, publisher confirms, acknowledgements, failure handling and connection management. Kubernetes teams add the operator module. Every track ends in a troubleshooting lab on a deliberately broken cluster.
The content is written for RabbitMQ 4.x: quorum queues are the default choice for durable work, Khepri is the only metadata store from 4.3, and classic queue mirroring is covered only as something to migrate away from. Checked against rabbitmq.com on 29 October 2026, when RabbitMQ 4.4.0 was current and 4.3 was the previous series.
What this page is, and where to book
This page is the detailed syllabus for the RabbitMQ workshop, and nothing on it is a booking page. The RabbitMQ training page owns the offer: who delivers it, remote and onsite formats, cohort size, the follow-up phase and how to request a quote.
Use this page to decide which modules your team needs and to check the prerequisites before you send people. The curriculum is tailored to your deployment in an assessment phase before the sessions start, so the modules below are the menu, and a team on Kubernetes with quorum queues will weight them differently from a team on virtual machines still moving off mirrored queues.
Tracks: who each one is for and what to know first
There are six tracks, and the choice is by role, not by seniority. The prerequisites are modest: command-line comfort and a cluster you are allowed to break for operators, and a working knowledge of your service language for developers. Neither main track requires prior RabbitMQ experience, and both work better when some of the room has some.
| Track | Who it is for | Prerequisites | Modules it leans on |
|---|---|---|---|
| Administrator | Platform and SRE teams who run the broker and get paged about it | Comfort on a command line and basic networking; no RabbitMQ experience needed | 3, 5, 6, 8, 9, 10, 11 |
| Developer | Engineers writing producers and consumers, where most throughput problems live | Working knowledge of the language your services use (Java, Python or .NET are typical); no RabbitMQ experience needed | 1, 2, 4, 11 |
| Kubernetes | Teams running RabbitMQ on Kubernetes | The Administrator prerequisites plus working Kubernetes knowledge | 3, 7, 10 |
| Troubleshooting workshop | Teams who already operate RabbitMQ and want to rehearse incidents | Working RabbitMQ familiarity; not a first course | 11, with 3, 5 and 6 as needed |
| Migration readiness | Teams moving from classic mirrored queues to quorum queues, or from another broker | Agreed in the assessment phase | 2, 4 |
| Custom curriculum | Estates where none of the standard tracks fit | Agreed in the assessment phase | Chosen from all eleven |
Course outline: the eleven modules, with outcome and exercise
Each module pairs a concept with immediate hands-on work against a lab cluster, so the outcome column describes what an attendee can do afterwards, not what they were told. The exercise shown is the typical one; it is adjusted to your deployment, versions and queue types during the assessment phase.
| # | Module | For | What attendees can do afterwards | Typical hands-on exercise |
|---|---|---|---|---|
| 1 | Architecture and core concepts | Developers, platform | Explain how a message queue broker routes a message through exchanges, bindings, routing keys and queues, what the broker guarantees and where the guarantees end, and which protocol (AMQP 0-9-1 or AMQP 1.0, native since 4.0) each client uses | Build a routing topology from the command line and the management UI, then break a binding and trace the lost messages |
| 2 | Queue types in depth | Developers, platform, migration teams | Choose classic, quorum or stream per workload. Know that quorum queues cannot be non-durable, exclusive or server-named, and that very long backlogs and large fan-outs suit streams | Declare one queue of each type and compare behaviour when a node stops |
| 3 | Clustering, Khepri and partitions | Platform, Kubernetes | Describe what a node holds, how the Raft-based metadata store and quorum queues behave when a node or link fails, and what recovery looks like. Pre-4.3 clusters on Mnesia also cover the legacy partition handling strategies | Partition a three-node cluster, observe which deliveries pause and which continue, then recover it |
| 4 | Publisher confirms and consumer acknowledgement | Developers, migration teams | Use confirms and manual acknowledgement correctly, set prefetch, make consumers tolerate redelivery, and explain where message loss really originates | Kill a consumer mid-message and watch unacknowledged messages requeue, then be redelivered as duplicates |
| 5 | Memory, disk and flow control | Platform | Read the memory and disk alarms before they fire, know that a tripped alarm blocks publishing connections, and set limits against real host or container limits | Trip a memory alarm on the lab cluster and recover publishers |
| 6 | High availability and disaster recovery | Platform | Size quorum queue membership, and choose between federation and shovel for cross-site flows with the trade-offs each imposes | Stand up a federation link and a shovel between two lab clusters and fail one over |
| 7 | RabbitMQ on Kubernetes | Kubernetes | Use the Cluster Operator and Topology Operator, size persistent volumes, set network policy for inter-node traffic, and run rolling updates that preserve quorum | Roll a node on a lab cluster and check queue membership afterwards |
| 8 | Management, CLI and plugins | Platform | Use the RabbitMQ management UI and HTTP API, rabbitmqctl and rabbitmq-diagnostics, and configure the plugins most estates use: shovel, federation, Prometheus and streams | Inspect a misbehaving node using only the CLI |
| 9 | Security and multi-tenancy | Platform | Design vhost isolation, users and least-privilege permissions, and TLS for clients and inter-node traffic, including the certificate mistakes that look like network faults | Replace an expiring certificate without an outage |
| 10 | Monitoring and observability | Platform, Kubernetes | Scrape the Prometheus plugin, build dashboards, and alert on leading indicators such as queue growth and alarm approach rather than on node death | Build an alert for a stalled consumer and trigger it |
| 11 | Production troubleshooting lab | All tracks | Diagnose a deliberately broken cluster under time pressure: memory alarms, backlogs, partitions and under-replicated quorum queues | Scenarios drawn from incidents we have resolved for customers |
How the labs work
Every module ends in a hands-on lab on a cluster you are free to break. Attendees use RabbitMQ the way an operator or a service developer would on a bad day: they stop and restart nodes, kill consumers mid-message, trip alarms and read the diagnostics. The point is to rehearse the failure once, in a lab, so the first real occurrence is not also the first time anyone has seen it.
Each session combines short explanation with exercises, and the labs run in the order shown in the module table. Three patterns recur across them.
- Restart and recover. Attendees restart a node, or roll the nodes of a cluster, and check that queue membership and message delivery come back as expected (modules 3, 6 and 7).
- Break a consumer. Attendees stop a consumer with messages unacknowledged and watch them requeue, to see why consumers must tolerate redelivery (module 4).
- Read the signals. Attendees use the management UI, the CLI and Prometheus metrics to find a fault, then set an alert so the next occurrence pages a person first (modules 8, 10 and 11).
RabbitMQ is an open-source message broker, and the labs use the same tooling your platform team will have in production.
What is taught for RabbitMQ 4.x, and what is not
The curriculum is quorum-first: it teaches quorum queues as the default for durable workloads and teaches classic queue mirroring only as a migration source, because mirroring was removed in RabbitMQ 4.0. Version-sensitive content was checked against rabbitmq.com on 29 October 2026.
| Topic | What the modules teach | Source |
|---|---|---|
| Current series | RabbitMQ 4.4.0 is current (released 20 October 2026); 4.3 is the previous series | rabbitmq.com release information |
| Metadata store | Khepri is the only metadata store from 4.3; Mnesia and partition handling strategies were removed. Khepri was the default for new clusters from 4.2 | Metadata store and partitions guides |
| Queue priorities | Quorum queues have strict priority with 32 levels from 4.3; earlier versions used two buckets | Priority queues guide |
| Poison messages | Quorum queues apply a delivery limit, which defaults to 20 from 4.0, then dead-lettered to a dead letter exchange if one is configured | Quorum queues guide |
| Erlang | 4.4.0 runs on Erlang 27.0 to 29.x; 4.3.6 on 27.0 to 28.x; Erlang 26 is end of life | Erlang version requirements |
| AMQP 1.0 | Native since 4.0, with no transactions and no link resume | AMQP 1.0 guide |
| Mirrored queues | Taught only as a migration source: removed in 4.0, with 3.13 as the last series that has them | Upgrade and migration guides |
Choosing who attends
Run the platform and developer tracks as separate groups, even on consecutive days. In our experience a room that mixes architects, platform engineers and application developers is pitched at the middle and is useful to nobody. The training page gives the cohort size we work with.
If one person is the only one who understands the cluster, send them to the Administrator track with their colleagues. The aim is to remove the single point of knowledge, and sending the expert alone does not do that.
Reinforcing it afterwards
Training decays without something to refer back to. Two public resources are written to be usable by someone who attended: the production readiness checklist, which lists what must be true before a cluster takes real traffic, and the troubleshooting decision tree, which starts from a symptom and ends in a command. Attendees also leave with a written reference guide specific to their deployment, as set out on the training page.
Ready to scope it
Tell us who is in the room and what they run, and we propose a module order and a quote. Requests go through the RabbitMQ training page, and we reply within 1 hour.
Frequently asked questions
What does a RabbitMQ training curriculum cover?
Architecture and message routing, queue types, clustering and partitions, publisher confirms and acknowledgement, memory and flow control, high availability and disaster recovery, Kubernetes, management and plugins, security, monitoring, and a troubleshooting lab on a deliberately broken cluster. Each track weights those modules for its audience.
Does the curriculum cover Khepri, quorum queues and RabbitMQ 4.4?
Yes. It is written for RabbitMQ 4.x. Quorum queues are taught as the default for durable work, Khepri as the metadata store (the only one from 4.3), and RabbitMQ 4.4, released on 20 October 2026, as the current series. Classic mirrored queues appear only as something to migrate away from.
Is this a RabbitMQ tutorial?
No. It is an instructor-led workshop, not a self-paced tutorial, and it is tailored to your deployment in an assessment phase first. The official tutorials on rabbitmq.com are a good way to learn the basic publish and consume patterns before you attend, and this curriculum picks up with production concerns: queue types, clustering, failure handling and monitoring.
What happens in the hands-on labs?
Each module has an exercise on a lab cluster, for example restarting a node and checking queue membership, killing a consumer mid-message to watch redelivery, or tripping a memory alarm and recovering publishers. The last module is a troubleshooting lab on a deliberately broken cluster.
Do attendees need RabbitMQ experience before the workshop?
Not for the Administrator or Developer tracks, which start from architecture fundamentals. Attendees should be comfortable with the command line and basic networking, and for the Kubernetes track with Kubernetes. The troubleshooting workshop assumes working RabbitMQ familiarity.
Should developers and platform engineers attend the same sessions?
We suggest separate tracks. Developers need confirms, acknowledgements and failure handling, and platform engineers need clustering, alarms and monitoring. A mixed room tends to be pitched at the middle.
Is the training a vendor certification?
No. It is practical training against your deployment, and attendees receive a certificate of completion rather than an accredited credential.