Skip to content
learn
Global menu

RabbitMQ — Mission

Why I’m learning this

Section titled “Why I’m learning this”

I have sent messages through RabbitMQ for years, mostly through a library that hid it: MassTransit on one project, Spring AMQP on another. It worked until the day it didn’t. A consumer restarted and some orders were processed twice; another time, messages vanished and nobody could say where they went. Each time I realised that I knew the library’s API and not the broker underneath.

I want to know what RabbitMQ actually does with a message from the moment a publisher sends it to the moment a consumer acknowledges it, so that I can design a topology on purpose, choose the right queue type, and find out what went wrong from the broker’s own tools.

Who this course is for

Section titled “Who this course is for”

You are a C# or Java developer. You have published or consumed messages, perhaps through MassTransit, NServiceBus, Spring AMQP or Spring Cloud Stream, and you have run a container before. You don’t need to know AMQP. The Java side assumes the level of Java for C# developers; lesson 3 sends Spring questions to Spring Boot, Spring Cloud and Reactor for C# developers, and lesson 1 sends container questions to WSL containers.

The running example

Section titled “The running example”

The lessons use small, recognisable flows rather than one application: log lines routed by severity, prices fanned out to several screens, orders and payments. A C# program (code/rabbitmq/csharp), a Java client program and a Spring Boot application (code/rabbitmq/java) exchange the same messages, because a broker is where different languages meet.

flowchart LR
    cs["C# publisher<br/>RabbitMQ.Client"] -->|order.created.eu| ex{{"orders.topic<br/>exchange"}}
    java["Java publisher<br/>amqp-client"] -->|order.created.us| ex
    spring["Spring publisher<br/>RabbitTemplate"] -->|order.created.ca| ex
    ex -->|"binding order.#"| q[("orders.billing<br/>queue")]
    q --> c1["C# consumer"]
    q --> c2["Java consumer"]
    q --> c3["Spring @RabbitListener"]

None of the GuitarAlchemist repositories uses RabbitMQ in its code, so there is no practical case from them yet; the journal notes the one configuration I found.

By the end of this course, I will be able to

Section titled “By the end of this course, I will be able to”
  • explain the AMQP 0-9-1 model: connections, channels, exchanges, bindings, queues and messages;
  • run RabbitMQ in a container and inspect it with the management UI, rabbitmqctl and rabbitmq-diagnostics;
  • design a topology with direct, fanout, topic and headers exchanges, and handle messages nothing routes;
  • write producers and consumers in C#, in Java and with Spring AMQP that interoperate;
  • say who is responsible for a message at each step, and use acknowledgements, prefetch, publisher confirms and persistence to lose none;
  • choose between classic queues, quorum queues and streams;
  • handle failures with dead lettering, TTLs and retries;
  • run a cluster, secure it, monitor it and size it;
  • operate RabbitMQ over time: upgrades, definitions, Kubernetes.

Outline

Section titled “Outline”
# Lesson You may already know
1 Getting started a queue from MassTransit or Spring, docker run
2 Topology: exchanges, bindings and queues Azure Service Bus topics and subscription rules, JMS destinations
3 Clients in C#, Java and Spring AMQP HttpClient lifetime, async consumers, RabbitTemplate
4 Reliability: acknowledgements, prefetch, confirms database transactions, at-least-once delivery
5 Queue types: classic, quorum and streams (coming next) Raft, Kafka partitions
6 Errors: dead lettering, TTL, retries and delayed messages Polly retries, MassTransit’s error queues
7 Patterns: work queues, publish/subscribe, RPC, competing consumers, outbox the transactional outbox of MassTransit or Spring Modulith
8 Clustering and high availability: network partitions, quorum failover clusters
9 Security: virtual hosts, users, permissions, TLS connection strings, certificates in Kestrel
10 Observability: Prometheus, Grafana, key metrics, alarms, flow control OpenTelemetry, dotnet-counters
11 Performance and sizing, measured BenchmarkDotNet
12 Other protocols: streams and super streams, MQTT, AMQP 1.0; RabbitMQ and Kafka Kafka, Azure Event Hubs
13 Operations: upgrades, definitions, the Kubernetes Cluster Operator Helm charts, rolling upgrades

Journal: what I tried, what surprised me, what I still need to verify.

Resources

Section titled “Resources”