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.
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 |
|
origin |
Processing of requests to send messages to users according to the settings of communication channels |
|
|
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.
-
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.