Skip to main content

Notification Event Architecture

Summary​

One topic exchange, one durable queue, 42 explicit bindings, one hosted consumer, one resolver and one dispatcher. The architecture is deliberately linear with no fan-out inside the service.

Audience​

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

Event architecture​

Publisher responsibilities​

Publishing services own their event contracts and emit onto the shared exchange with the event type as the routing key. Notification asserts nothing about how they produce those events; that is each owning module's concern.

Notification's only use of the publisher side is the test hook, which places an arbitrary caller-supplied event type and payload onto the same exchange.

Consumer responsibilities​

The consumer owns four things: declaring the exchange and queue idempotently, binding the 42 supported event types, normalising each delivery into an envelope, and acknowledging.

It deliberately owns no business logic. Parsing is a static method; everything after it is delegated to the dispatcher resolved from a fresh scope per delivery, which keeps the scoped persistence context per-message rather than per-service-lifetime.

Broker participation​

The exchange is declared as topic, durable and not auto-deleted. Bindings are nevertheless exact event-type strings — no wildcard pattern is used — so the topology behaves like a direct exchange in practice while retaining the ability to add pattern bindings later.

Connection handling is resilient by construction: automatic recovery is enabled with a fixed network recovery interval, and the hosted service wraps connection establishment in an indefinite retry loop with a fixed delay, so a broker that is unavailable at startup never crashes the service.

Delivery flow​

Messages are consumed with automatic acknowledgement disabled and a configurable prefetch, so the broker holds delivery until the service explicitly acknowledges. Success acknowledges the single delivery tag; any unhandled exception negatively acknowledges with requeue and is logged.

Current maturity​

Transitional.

Classification​

Transitional.

Requires confirmation​

The deployed broker topology, including whether additional bindings or consumers exist outside the repository, requires confirmation.

See Also​

Keywords​

  • Notification database
  • Event Architecture
  • Draft database documentation

Source References​

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

Revision Information​

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