In one of my recent projects, I optimized the email notification system by introducing the Factory Design Pattern, XSLT-based email generation, and a single reusable email template. The solution supports more than 30 notification types while remaining scalable, consistent, and easy to maintain.
The application follows a .NET Core microservice architecture. Business events are published asynchronously through RabbitMQ or Apache ActiveMQ Artemis, while a dedicated notification service consumes these events and generates the required emails.
A common challenge with large notification systems is the increasing number of templates and duplicated implementation logic. Approval notifications, reminders, workflow updates, account alerts, and status change emails often require different content, but they typically share the same layout, branding, and delivery workflow. Maintaining separate templates and implementations for every notification type results in code duplication and makes future changes difficult.
To address this challenge, I designed a centralized notification workflow using the Factory Design Pattern.
Each event message contains a notification type along with the required business data. The email factory identifies the notification type and resolves the appropriate notification handler. Each handler is responsible only for preparing notification-specific information, such as recipients, subject lines, and the structured data required for the email.
The structured data is converted into XML and passed through an XSLT transformation. XSLT generates the final HTML email by applying the notification-specific XML data to a shared email template. This approach allows a single reusable template to provide consistent headers, footers, branding, styling, and overall layout while dynamically rendering content for each of the 30+ notification types.
Notification Workflow
A business microservice performs an action, such as request creation, approval, rejection, reminder, or status update.
The microservice publishes a notification event to RabbitMQ or Apache ActiveMQ Artemis.
The notification microservice consumes the event asynchronously.
The Factory resolves the appropriate notification handler based on the notification type.
The selected handler prepares the recipients, subject, and XML data model.
XSLT transforms the XML into the final HTML email using the common email template.
The email is sent, and processing, delivery status, and audit information are stored in SQL Server.
Benefits of the Implementation
A single shared email template ensures consistent branding and layout across all notifications.
Support for more than 30 notification types without maintaining separate HTML templates.
Clear separation of notification-specific business logic from email presentation logic.
Cleaner, extensible, and maintainable code through the Factory Design Pattern.
Simplified template management using XSLT transformations.
Asynchronous and resilient processing through RabbitMQ and Apache ActiveMQ Artemis.
Improved traceability through notification history and audit records stored in SQL Server.
Easy onboarding of new notification types by adding a new handler and XML data model without modifying the core notification workflow.
![ChatGPT Image Jul 23, 2026, 03_34_50 PM]()
Conclusion
The Factory Design Pattern eliminated large if-else and switch statements from the notification service by delegating each notification type to its dedicated handler. XSLT introduced a clean presentation layer that generates dynamic HTML emails from structured XML, enabling a single reusable template for all notification scenarios.
Together, these design decisions transformed the email notification system from a collection of individual implementations into a reusable, scalable notification platform. By combining .NET Core, microservices, RabbitMQ, Apache ActiveMQ Artemis, SQL Server, the Factory Design Pattern, XML, and XSLT, the solution became easier to maintain, more reliable, and well prepared to support future notification requirements.