Notification Exchanges, Queues and Routing Keys

Summary

A reference table of every broker object the service declares, and the routing-key convention that connects them.

Audience

DevOps engineers, engineers, architects, QA and support.

Reference Content

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

Declared objects

Object	Kind	Durable	Auto-delete	Exclusive	Arguments
Integration-events exchange	Topic	Yes	No	—	None
Notification events queue	Queue	Yes	No	No	None

Both names are configurable — the exchange through the shared broker options section, the queue through the Notification options section — and both have defaults in source.

Routing-key convention

The routing key is the event type string, on both sides:

• The shared event bus publishes with the routing key set to the event type, and additionally sets the AMQP type property to the same value.
• The consumer binds each supported event type as a literal routing key.
• When neither the type property nor the event-type header is present, the consumer falls back to reading the routing key as the event type, which closes the loop.

There is no namespacing, no dotted hierarchy and no wildcard in any routing key. Event types are flat identifiers such as the employee-created or ticket-escalated names.

Note the distinction from template keys: the Asset and Performance families use dotted template keys, but their routing keys remain flat event-type strings.

Binding set

42 bindings, one per supported event type, all against the single queue. The binding list is derived at runtime from the resolver's supported-types array rather than from configuration, so the code that decides what the service can handle is also the code that decides what it subscribes to — the two cannot drift apart.

Bindings are created with no arguments, which is required for a topic exchange binding without header matching.

Consumption parameters

Parameter	Value
Automatic acknowledgement	Disabled
Prefetch count	Configurable, default 5
Prefetch size	0, meaning unlimited by octet count
Global QoS	False — applies per consumer
Consumer type	Asynchronous eventing consumer

Verified absence

No secondary queue, no retry queue, no delay queue, no dead-letter exchange declaration, no alternate exchange, no priority setting, no message time-to-live, no queue length limit and no quorum or stream queue type is declared.

Classification

Implemented.

Requires confirmation

Whether operator-applied broker policies supplement these declarations requires confirmation.

Related Articles

• Broker topology
• Consumed events
• Publishers

See Also

• Dead-letter processing
• Consumers

Keywords

• Notification database
• Exchanges & Queues
• 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