notification service

hld

mermaid-diagram (11).svg

lld

API Endpoints

Method	Endpoint	Purpose
GET	`/info`	Service health check
POST	`/tickets`	Create email ticket (status = PENDING) for async dispatch

Critical Logic Flow: Async Queue Processing

Scenario: The Booking Service successfully processes a payment and pushes a notification event. The Notification Service consumes it and sends an email.

mermaid-diagram (12).svg

. Important Points (The "Why")

Why use RabbitMQ instead of calling the Email Service directly via HTTP?
- Answer: Email SMTP servers are notoriously slow and prone to latency spikes. If the Booking Service waited for an HTTP response from the Email Service, it would block the user UI. RabbitMQ decouples this: the Booking Service drops a message in noti-queue instantly, returning a fast response to the user, while this service handles the slow dispatch in the background.
Why require manual acknowledgement (channel.ack)?
- Answer: To guarantee delivery. If the Notification Service crashes while sending an email, we don't want the message lost. By calling ack() only after sendEmail resolves, unacknowledged messages will safely return to the queue if the connection drops.
Why maintain a Ticket table in the database?
- Answer: Auditing and Retry Mechanisms. Using the TicketRepository.getPendingTickets() method , we can run a cron job to fetch tickets stuck in the PENDING state and attempt to retry dispatching them in case of temporary SMTP failures .
  
  +2