Producers publish to exchanges; bindings define which queues receive a message; consumers read from queues and acknowledge processing. Exchanges do not store messages like queues, and an acknowledgement is not an end-to-end business transaction.
Topology basics
Choose direct, topic, fanout, or headers exchanges from routing requirements. Declare queue durability, exclusivity, auto-delete, arguments, queue type, and bindings explicitly. Handle unroutable publications with mandatory returns or an alternate exchange when required.
Define “replay” precisely
| Need | Mechanism |
|---|---|
| Transient processing failure | Bounded delayed retry plus dead-letter quarantine |
| Unacknowledged delivery | Broker redelivery; consumer must be idempotent |
| Retained sequential log | RabbitMQ Streams with offset-based consumption |
| Historical business reprocessing | Application-owned immutable event store and controlled republisher |
Do not repeatedly requeue poison messages. Preserve original message identifiers, schema version, timestamp, source, attempt count, and replay authorization. A replay can duplicate side effects or violate current policy.
Test the project
- Verify each routing-key/binding case and unroutable behavior.
- Crash consumers before and after side effects to test idempotency.
- Test TTL, dead lettering, retry exhaustion, retention, ordering, and duplicate replay.
- Authorize replay separately, limit rate, isolate targets, record operator/reason, and reconcile results.
- Exercise node/network failure and restore with the selected queue or stream type.
Continue with advanced routing, messaging fundamentals, and the local setup.
Reviewed against current RabbitMQ documentation September 4, 2026. Original publication date preserved.
Historical comments from Datanizant
No public comments on this article
No approved public comments were included in the WordPress export for this article.