Skip to main content

Notification Published Events

Summary​

The Notification Service publishes no business event. There is no outbound event contract, no publisher call in any application service, no domain event and no outbox. The only code path that reaches the broker is the test-publish endpoint.

Audience​

Engineers, architects, QA, support, security reviewers and implementation partners.

Reference Content​

The verified reference material for this topic is set out in the sections below.

Inventory​

Published eventCount
Business or lifecycle events0
Domain events0
Outbox-relayed events0

There is nothing to catalog. This page records the verified absence.

Verified absence​

  • No type in the service derives from the shared IntegrationEvent contract.
  • No call to the integration-event publisher abstraction appears anywhere in the service.
  • The dispatcher, the resolver, the template engine, the preference evaluator, the channel senders and the seeder contain no publish call.
  • No outbox entity, table or relay exists — the persistence context maps seven entities and none of them is an outbox.
  • The shared messaging registration resolves an outbox processor only when a message store is registered; Notification registers none, so the no-operation processor is selected.

The one publish path​

The test-publish endpoint takes an event bus dependency and places a caller-supplied event type and payload onto the shared exchange. Startup source records the reason for the bus registration explicitly: it exists for that hook.

That path publishes an arbitrary event type — whatever the caller names — not a Notification-owned contract. It is a verification affordance, documented in event testing, and it is not an outbound integration contract.

Consequences​

No delivery feedback loop. Other modules cannot react to notification outcomes. A module that needs to know whether its notification was delivered, failed or was read has no event to subscribe to; it would have to query the Notification API.

Terminal position in the event graph. Notification is a leaf consumer. Nothing downstream depends on it emitting anything, which also means its failures are invisible to the rest of the platform except through logs, audit rows and the failed-message queue.

No fan-out risk. Because it publishes nothing, Notification cannot create event storms or feedback cycles.

Classification​

Not implemented.

Requires confirmation​

Whether outbound events such as delivery succeeded, delivery failed or notification read are planned for other modules to consume requires confirmation.

See Also​

Keywords​

  • Notification database
  • Published Events
  • Draft database documentation

Source References​

  • microservices/src/notification-service/Api/NotificationEndpoints.cs
  • microservices/src/notification-service/Program.cs
  • microservices/src/shared-kernel/Extensions/MessagingExtensions.cs
  • microservices/src/notification-service/Application/NotificationDispatcher.cs
  • microservices/src/notification-service/Domain/NotificationEntities.cs

Revision Information​

  • Status: Draft
  • Last reviewed: 2026-07-21
  • Review cycle: Quarterly