Skip to main content

Notification Service

Service Type Deployable backend service Language Kotlin / Micronaut Database PostgreSQL Messaging Apache Kafka External Integrations Kafka, PostgreSQL; notification delivery channel unknown Status: Implemented (v0.1)

Overview​

whitelabel/notification-service provides a centralized notification inbox for users of the DEUSS platform. It consumes notification events from Kafka, creates persisted notifications for individual recipients, and exposes authenticated APIs for retrieving notifications and marking them as read.

Business Responsibilities​

  • Consume notification creation events.
  • Create notifications for one or more recipient users.
  • Store notification payloads and metadata.
  • Provide users with paginated notification history.
  • Filter notifications by read status and creation date.
  • Sort notifications by creation time or read status.
  • Mark individual notifications as read.
  • Support multiple business notification types. Verified notification types include:
  • COMPANY_NEW_INVITATION
  • COMPANY_INVITATION_ACCEPTED
  • BOND_PROPOSAL
  • BOND_ISIN_REQUEST_RESULT

Owned Data​

The service owns the persisted user notification records, including:

  • Notification identifier
  • Recipient user identifier
  • Notification type
  • Generic notification payload
  • Creation timestamp
  • Read/unread status The data is stored in a PostgreSQL database owned by the service.

Interfaces​

Inbound Interfaces​

REST API​

  • GET /notification/my
    • Returns notifications for the authenticated user.
    • Supports pagination.
    • Supports filtering by:
      • Read status
      • Creation date
    • Supports configurable sorting.
  • PATCH /notifications/{notification_id}
    • Marks a notification as read.
    • Requires the authenticated user to have access to the notification.

Kafka​

  • Consumes notification creation events from the shared notification topic.

Outbound Interfaces​

  • No outbound REST clients were verified.
  • No GraphQL clients were verified.
  • Notification delivery is abstracted through the NotificationSender interface.
  • A concrete SSE, WebSocket, push-notification, or external delivery implementation was not verified.

Kafka Producers & Consumers​

Producers​

No Kafka producers were identified in the service.

Consumers​

  • NotificationEvents.CREATED
    • Receives a notification creation event.
    • Creates one persisted notification record per recipient user.

External Integrations​

PostgreSQL​

Used as the authoritative persistence store for user notifications.

Kafka​

Used for asynchronous notification creation events.

Notification Delivery Channel​

The service contains a NotificationSender abstraction intended to support delivery to users. The concrete delivery mechanism is not verified in the current implementation.

Business Rules​

  • Notifications are created separately for each recipient.
  • Notifications are associated with a specific recipient user.
  • Users can retrieve only their own notifications through the public API.
  • Notifications can be filtered as:
    • All
    • Read
    • Unread
  • Marking a notification as read is performed using the notification identifier.
  • Notification payloads are generic and their structure depends on the notification type.

Processing & Error Handling​

  • Kafka events are converted into persisted notification records.
  • Notifications are stored before they are returned through the REST API.
  • The notification payload is optional at persistence level.
  • The service supports paginated retrieval to avoid returning the complete notification history in a single response.

Observability​

  • The service uses the common DEUSS logging framework.
  • Kafka listener processing and notification operations are logged.
  • No dedicated metrics, tracing integration, or alerting configuration was verified in the inspected module.

Relationships to Other Components​

  • Other services publish NotificationEvents.CREATED.
  • notification-service consumes these events and persists the user notifications.
  • Client applications retrieve notifications through the REST API.
  • A future or external delivery component may use NotificationSender for real-time notification delivery.

Deployment Topology​

  • Deployable Kotlin/Micronaut application.
  • Runs as an independent service.
  • Uses PostgreSQL for persistent storage.
  • Uses Flyway for database migrations.
  • Runs as a Kafka consumer with the consumer group notification-service.
  • Does not own blockchain data.
  • Does not use object storage.
  • No direct dependency on another DEUSS service was verified.

Architecture Notes & Inconsistencies​

  • The service has a clear asynchronous ingestion model through Kafka and a synchronous read model through REST.
  • NotificationSender is currently an abstraction; the active delivery technology is unknown.
  • The OpenAPI specification uses both recipientUserId and recipientId in different sections. This naming should be unified.

Source References​

  • whitelabel/notification-service/src/main/kotlin/cz/deuss/notificationservice/controller/NotificationController.kt
  • whitelabel/notification-service/src/main/kotlin/cz/deuss/notificationservice/kafka/NotificationEventsListener.kt
  • whitelabel/notification-service/src/main/kotlin/cz/deuss/notificationservice/service/NotificationService.kt
  • whitelabel/notification-service/src/main/kotlin/cz/deuss/notificationservice/delivery/NotificationSender.kt
  • whitelabel/notification-service/src/main/resources/application.yaml
  • whitelabel/notification-service/src/main/resources/db/migration/
  • api-specifications/src/main/resources/whitelabel/notification-service/public/notification-service-public.openapi.yaml