Message broker
A middleman that stores and routes messages so senders and receivers can work at different times and speeds.
See it
What it is
A message broker accepts messages from producers, holds or routes them, and delivers them to consumers without requiring both sides to be available at the same moment. RabbitMQ centers queues and exchanges; Apache Kafka, built at LinkedIn to move activity streams, keeps an ordered log split into partitions. Both connect systems asynchronously, but their storage and delivery models differ.
Reach for one when work should survive a brief outage, several services need the same event, or a slow consumer must not block the request that created the work. The broker becomes a buffer and a boundary between independently deployed producers and consumers.
Gotcha: delivery is commonly at least once, so a consumer can receive the same message again after a timeout or crash. Ordering is limited by queue or partition boundaries, and a growing backlog is delayed work, not free storage. Use idempotent handlers, explicit acknowledgements, bounded retries, dead-letter handling, and backlog alerts.
Ask AI for it
Wire this workflow through RabbitMQ using a durable topic exchange, quorum queues, persistent messages, publisher confirms, and manual consumer acknowledgements. Define routing keys and a versioned JSON Schema, make the consumer idempotent with a database-backed message id, retry transient failures with a bounded retry ladder of per-attempt queues that set x-message-ttl and x-dead-letter-exchange, and route exhausted messages through a dead-letter exchange. Output the topology declaration, producer and consumer code, and integration tests that cover duplicate delivery and consumer restart.