Skip to main content

Notification Broker Topology

Summary​

One durable topic exchange, one durable queue and 42 exact-match bindings, all declared by the consumer at connection time. Dead-letter names are configured but the queue is declared without them.

Audience​

DevOps engineers, engineers, architects, QA, support and security reviewers.

Broker topology​

Exchange​

Declared by the consumer as a topic exchange, durable and not auto-deleted. The name comes from the shared broker options and defaults to the platform integration-events exchange. Declaration is idempotent, so the consumer can declare it safely whether or not a publisher already has.

The same exchange is used by the shared event bus for publishing, so one exchange carries the platform's integration traffic.

Queue​

Declared as durable, non-exclusive and not auto-deleted, with the name taken from the Notification configuration section and defaulting to a service-specific queue name.

Critically, it is declared with no arguments. That is the mechanism by which dead-letter routing, message time-to-live, maximum length and queue type would be set — none are.

Bindings​

The consumer iterates the resolver's supported event types and creates one binding per type, using the event type string as the routing key. That produces 42 bindings.

Although the exchange is a topic exchange, every binding is an exact string — no wildcard patterns are used — so routing behaves like a direct exchange today. Adding a supported event type requires a resolver entry, and the binding follows automatically on the next connection.

Prefetch​

Quality of service is set with a configurable prefetch count defaulting to 5, applied per consumer rather than globally. Automatic acknowledgement is disabled, so the broker withholds acknowledgement until the service acknowledges explicitly.

Prefetch above one is what allows concurrent in-flight deliveries; see ordering.

Connection resilience​

The connection factory enables automatic recovery with a fixed network recovery interval. Above that, the hosted service wraps connection establishment in an indefinite loop that logs a warning and retries after a fixed delay when the broker is unreachable, so an unavailable broker never crashes startup.

On shutdown the channel and connection are disposed after the base stop completes.

Dead-letter configuration​

The Notification options declare a dead-letter exchange name and a dead-letter queue name. Neither is referenced anywhere else in the service. See dead-letter processing.

Scope boundary​

Everything above is what the repository declares. The deployed broker may have additional exchanges, queues, policies, mirroring or operator-defined dead-letter policies applied out of band. This documentation asserts nothing about infrastructure outside the repository.

Classification​

Transitional — declaration is Implemented; dead-letter topology is Not implemented in code.

Requires confirmation​

The deployed broker topology, including any operator-applied policies, requires confirmation.

See Also​

Keywords​

  • Notification database
  • Broker Topology
  • Draft database documentation

Source References​

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

Revision Information​

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