A RabbitMQ architecture for notification systems
Queue topology, retries and dead-letter handling for systems that must not silently drop messages.
Separate what fails differently
Email, SMS and push notifications fail in different ways and at different rates. Putting them on one queue means the slowest, flakiest provider decides your throughput. One queue per channel — and per priority class where it matters — keeps failures contained.
Retries need a ceiling and a graveyard
Exponential backoff with a bounded retry count, then a dead-letter queue. A message that cannot be processed must end up somewhere a human can inspect it, not loop forever burning worker capacity.
The dead-letter queue is only useful if someone is alerted on its depth. Monitor it like you monitor error rate.
Idempotency is not optional
At-least-once delivery means your consumer will see duplicates. Store the provider event ID before processing and treat a repeat as a no-op. This single habit removes an entire category of production bug.