User notification subsystem

🌐 This document is available in both English and Ukrainian. Use the language toggle in the top right corner to switch between versions.

1. General description

The User notification subsystem aims to receive and process requests for sending notifications to users according to personal settings and communication channels supported by the registry.

2. Subsystem functions

  • Forming based on the configured template and sending mail notifications using the platform or external SMTP server according to the current registry settings

  • Sending push-notifications to external notification service - citizen-facing solution. For example, in Ukrainian case this referes to Diia mobile application

  • Forming based on a customized template and creating in-app-notifications in the Inbox of the user’s cabinet

  • Viewing the list and confirming the viewing of in-app messages by the user

3. Subsystem technical design

This diagram shows the components included in the Subsystem of user notifications and their interaction with other subsystems within the implementation of functional scenarios.

notifications subsystem design

3.1. Audit and event logging

Technical article section under development…​

Events of sending messages to users by the system are recorded in the audit log with full context.

Event type Official title Description

SYSTEM_EVENT

SEND_USER_NOTIFICATION

Attempting to send a message with the result of the operation

More information about the design of the Audit Event Logging Subsystem is here by link.

4. Subsystem components

Component name Representation in the registry Source Repository Purpose

User notification service

ddm-notification-service

origin

github:/epam/edp-ddm-notification-service

Processing of requests to send messages to users according to the settings of communication channels

Operational database of notifications

operational:notifications

origin

github:/epam/edp-ddm-registry-postgres/tree/main/platform-db/changesets/notifications

Storage of notification templates and user`s inbox notifications

5. Technological stack

During the design and development of the subsystem, the following technologies were used:

6. Subsystem Quality Attributes

6.1. Scalability

User Notification subsystem supports both horizontal and vertical scaling.

More information about scaling subsystems in the relevant sections can be found here:

6.2. Security

User Notification subsystem provides an API for viewing personal inbox messages through the cabinet to authenticated users and is only accessible through the External Traffic Management Subsystem.

6.3. Observability

User notification subsystem supports logging and collection of performance metrics for further analysis through the web interfaces of the corresponding subsystems of the Platform.

More information about the design of subsystems can be found in the relevant sections:

6.4. Auditability

User notification subsystem captures significant technical and business events related to the operation of the system by end users.

More information about the design of the subsystem can be found in the relevant sections:

6.5. Interoperability

User notification subsystem currently supports the following communication channels with users:

inbox

Sending in-app messages to the inbox of user accounts.

email

Sending mail messages to users using a platform or external mail server.

diia
This functionality is specific to the Ukrainian implementation and may not apply or function as described in other contexts or regions. Please consult the local guidelines or documentation if you are implementing this outside Ukraine.

Sending push-notifications to external notification service through an external API-gateway. For example, in Ukrainian case this referes to Diia mobile application.