New: Cookbooks and AI ExplanationsStep-by-Step recipes to solve problems connected to Roadmaps and Cheat Sheets. Need more details? Use AI buttons for structured and simple explanations with concrete examples throughout the whole platform.Take a look
Every service I add ends up with its own queue wired straight to the producer, and the producer now has to know about all of them.
What you'll have at the end
One topic exchange that lets a new service subscribe to the events it needs without a single change to the publisher
You need
A producer that already publishes at least one event other services react to, currently by naming or declaring each consumer's queue right inside the producer's own code.
Not covered
Changing an event's payload shape once consumers already depend on it, and making a consumer that receives the same event twice behave safely; both come after the routing itself no longer ties the producer to its consumers.
Leans on
Make your queue consumer idempotent
a wildcard binding can hand one event to more than one queue at once, and a consumer that gets redelivered a message it already handled needs to tolerate seeing it twice.
Should this event stream run on RabbitMQ or Kafka?
once the number of independent subscribers on one event stream keeps growing, this is the recipe that helps decide whether RabbitMQ is still the right broker for it.
Checked 19 Aug 2026
Part of the Message Queues cookbook