backend

Distributed Notification System

Event-driven notifications with RabbitMQ, retries, and DLQ

Problem

Sending notifications synchronously from API handlers creates slow responses and single points of failure when SMTP or SMS providers go down.

What I built

Built a publisher–consumer architecture where the API gateway publishes events to RabbitMQ and dedicated workers handle delivery, retries, and logging.

Architecture

REST API → RabbitMQ topic exchange (notifications.topic) → queue.email / queue.sms / queue.push → consumer services → external providers. Failed messages requeue up to 3 times, then land in a DLQ.

API highlights

• POST /signup — publishes user.signup.email event
• POST /order — publishes order.completed.email event
• POST /notify — generic notification dispatch

Challenges

• Getting ACK/NACK semantics right so messages aren't lost or duplicated
• Designing routing keys that scale when new notification types are added