Skip to main content

Notification Technical Limitations

Summary​

The Notification Service is functional and event-driven but Transitional. The following verified limitations are grouped by concern. Each reflects the reviewed source, not runtime configuration.

Architecture​

  • No separate engine, worker, dispatcher daemon, processor or outbox relay — orchestration and delivery run in-process within one consumed-event scope.
  • The application layer couples directly to NotificationDbContext; there is no repository or unit-of-work abstraction.
  • Two implementations (extracted service and legacy monolith) coexist with different contracts and template models.

Delivery​

  • SMS and WhatsApp are placeholders with no real provider; they log simulated deliveries.
  • Email delivers only when an address is resolvable; the active email provider is chosen once at startup.
  • Delivery is synchronous within the dispatch scope, with no asynchronous delivery queue or batching.

Retry​

  • Retry is a bounded in-process loop; there is no persisted retry queue or scheduled re-drive.
  • The dead-letter exchange/queue names are configured but not wired (the queue is declared with null arguments).
  • Automatic re-drive of already-failed messages is not implemented; re-driving is manual via the retry endpoint.

Processing​

  • Processing is single-pass and synchronous with no reprocessing scheduler.
  • Workflow and most Recruitment events are absent from the resolver’s supported event types.

Authorization​

  • No authentication or authorization is registered; all endpoints are anonymous.
  • Recipient identity on the inbox endpoint is caller-supplied and unverified.
  • There is no context-wide tenant guard; tenant scoping relies on per-query parameters and upstream enforcement.

Validation​

  • Validation is minimal and inline; there is no validation framework or domain invariant enforcement.
  • Template rendering is intentionally tolerant, silently emptying unknown placeholders.

Compatibility​

  • The gateway routing toggle defaults off, so notification traffic stays on the monolith unless enabled.
  • The portal inbox still calls legacy monolith endpoints; cutover to the extracted contract is not evident.

Testing​

  • Only a smoke script and in-service test hooks exist; there are no unit, integration or contract test projects for the service.

Requires Confirmation​

Production provider selection, dead-letter enablement, access enforcement, canonical implementation and test ownership require confirmation.

Source References​

  • microservices/src/notification-service/Program.cs
  • microservices/src/notification-service/Application/NotificationDispatcher.cs
  • microservices/src/notification-service/Channels/PlaceholderSenders.cs
  • microservices/src/notification-service/Messaging/NotificationEventConsumer.cs

See Also​

Keywords​

Limitations, constraints, gaps, verified absence, transitional.

Revision Information​

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