Skip to main content

Notification Compatibility

Summary​

Two notification implementations coexist: the extracted service and the legacy monolith path. The gateway routes notification traffic to the extracted service only when a feature toggle is enabled; by default it stays on the monolith. The portal inbox currently calls legacy monolith endpoints.

Routing overview​

Gateway feature toggle​

The gateway exposes NotificationRouting:UseNotificationService (also settable via the NOTIFICATION_ROUTING_USE_NOTIFICATION_SERVICE environment key), defaulting to false. When off, the notifications owned prefix stays on the monolith; when on, it routes to the notification-service cluster. A shadow route sends /notifications/** to the extracted service, and a route-source header distinguishes notification-service, notification-service-shadow and monolith. The extracted-service cluster resolves its base address from configuration, defaulting to port 5074.

ESS gateway integration​

The gateway’s employee self-service endpoints read the inbox from the extracted service /notifications/my for the resolved recipient reference, independent of the main routing toggle.

Legacy coexistence​

The monolith retains NotificationsController and NotificationTemplatesController with a different endpoint contract and template model. The extracted service serves un-prefixed endpoints (/notifications/*, /notification-templates/*), while the monolith serves /api/notifications. The two template models are not shared.

Portal surface​

The client inbox page calls legacy monolith endpoints (/notifications/all, /notifications/{id}/read, /notifications/read-all). The extracted service exposes a different inbox contract (/notifications/my, /notifications/{id}/read). Portal cutover to the extracted contract is not evident in the reviewed source.

Verified absence​

There is no monolith-shaped compatibility controller inside the extracted service and no shared template schema between the two implementations.

Requires Confirmation​

Production toggle state, the canonical implementation, portal cutover plans and migration of legacy notification records require confirmation.

Source References​

  • microservices/src/gateway-api/Program.cs
  • microservices/src/gateway-api/EssEndpoints.cs
  • Controllers/NotificationsController.cs
  • UI/salary-ui/apps/client-hrms-portal/src/pages/NotificationsPage.tsx

See Also​

Keywords​

Compatibility, gateway toggle, legacy coexistence, routing, shadow route.

Revision Information​

  • Status: Draft
  • Last reviewed: 2026-07-21
  • Next review: 2026-10-21