Skip to main content

Notification Events and Integration Contracts

Summary​

Complete Draft event documentation for Notification. The service is a pure consumer: it subscribes to 42 integration event types on one topic exchange and publishes no business event of its own. Its only publish path is a test hook.

Audience​

Developers, QA engineers, support engineers, DevOps engineers, security engineers, solution architects and implementation partners.

Overview​

Notification participates in the platform's event-driven architecture in one direction only. A single hosted BackgroundService binds one durable queue to the shared topic exchange with 42 explicit bindings, one per supported event type. Each delivery is normalised into a NotificationEventEnvelope, handed to the dispatcher in its own dependency-injection scope, and acknowledged on success or negatively acknowledged with requeue on an unhandled failure.

Three characteristics define the event surface and recur throughout this section:

  • Consumption only. The service declares no domain event, no outbox and no integration-event publisher of its own. The IEventBus dependency exists solely to serve the test-publish endpoint.
  • Envelope fields are carried but not all are used. The envelope models eleven fields; the schema version, causation identifier and user identifier are parsed and then never read by any downstream logic.
  • Dead-letter is configured but not wired. Dead-letter exchange and queue names exist in configuration, while the queue is declared with no dead-letter arguments.

The module is classified Transitional.

Documentation map​

Start with the events overview and event architecture.

Inventories are in consumed events — the authoritative 42-event catalog — plus published events, domain events and integration events.

Transport is covered in event envelopes, broker topology, exchanges and queues, publishers and consumers.

Processing semantics are covered in handlers, correlation, idempotency, retry and redelivery, dead-letter processing and ordering.

Evolution and verification are covered in versioning, compatibility, event testing, event limitations and the source map.

Classification​

Transitional. Consumption, correlation and idempotency are Implemented; dead-letter processing, event versioning and published events are Not implemented; ordering and event testing are Partial.

Requires confirmation​

Broker topology outside the repository, whether the dead-letter path is intended to be wired, and whether Notification is expected to publish events of its own require confirmation.

See Also​

Keywords​

  • Notification events
  • Integration contracts
  • Draft event documentation

Source References​

  • microservices/src/notification-service/Messaging/NotificationEventConsumer.cs
  • microservices/src/notification-service/Messaging/NotificationEventEnvelope.cs
  • microservices/src/notification-service/Application/EventNotificationResolver.cs
  • microservices/src/shared-kernel/Messaging/RabbitMqEventBus.cs
  • microservices/src/shared-kernel/Messaging/RabbitMqOptions.cs

Revision Information​

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