top of page
Search

High Level Component Design for a email notification system

  • Writer: varun sudan
    varun sudan
  • Feb 5, 2022
  • 1 min read

ree

Explanation of the flow : Step: 1. Action on an entity within the source system generates an event.

Step: 2. Process incoming message, with configurable in-memory retry logic

Step: 3. In case of failure to process the message, put it in the DLQ[Dead Letter Queue]. Alerts can be triggered based on queue depth.

Step: 4-5. If rules exist within a system for generated events, apply the rules to get a full-formed message. If there are no corresponding rules drop the message.

Step: 6. Process incoming message, with configurable in-memory retry logic.

Step: 7. In case of failure to process the message, put it in the DLQ[Dead Letter Queue]. Alerts can be triggered based on queue depth. Replay logic can be built based on error types.

Step 8. Log incoming message to DB for auditing purposes. This can be used to build replay logic.

Step 9-10. Apply email template to form a fully flushed out message and add it to the DB before sending out the next queue.

Step 11. Drop the fully formed message to the queue.

Step: 12. Process incoming message, with configurable in-memory retry logic.

Step: 13. In case of failure to process the message, put it in the DLQ[Dead Letter Queue]. Alerts can be triggered based on queue depth. Replay logic can be built based on error types.

Step 14. Log incoming message to DB for auditing purposes. This can be used to build replay logic.

Step 15-17. Send email outgoing SMTP server. Update the delivery status for the given record in DB.

 
 
 

Recent Posts

See All
Transactional Outbox Design

The Transaction Outbox design pattern is particularly useful in scenarios where you need to ensure reliable and consistent communication...

 
 
 

Comments


bottom of page