Skip to content

Patterns & Alternatives

You now know the machinery — exchanges, queues, acknowledgements, confirms, dead-letter exchanges. This final module is about judgement: which pattern fits which problem, when RabbitMQ is the wrong tool, and how to assemble everything you’ve learned into a consumer you can trust in production.

LessonWhat you’ll learn
Messaging patternsWork queues, pub/sub, routing, RPC, and event-driven choreography — and when to use each
RabbitMQ vs KafkaQueue semantics versus a replayable log, and how to choose
RabbitMQ StreamsAn append-only, replayable log built into RabbitMQ
Designing a resilient consumerA production-grade consumer that ties every reliability lesson together

Every pattern in this course is a different shape of the same publish-route-consume flow:

flowchart TB
  ev["An event or task"] --> q1["Work queue
(one worker of many does it)"]
  ev --> q2["Pub/sub
(every subscriber gets a copy)"]
  ev --> q3["Routing/topic
(only matching consumers)"]
  ev --> q4["RPC
(request, wait for reply)"]
The patterns are all shapes of one flow

The skill is not memorising each one — it is recognising, when a new requirement lands on your desk, which shape it is. That recognition is what the rest of this module builds.

What is this final module mainly about?
What do work queues, pub/sub, routing, and RPC have in common?
Where does a senior engineer add the most value with messaging?