Skip to main content

Notification Message Ordering

Summary​

No ordering guarantee exists. Nothing in the reviewed source preserves, asserts or restores event order, and several verified factors actively break it.

Audience​

Engineers, architects, QA, support and DevOps engineers.

Verified absence​

  • No sequence number, version number or ordinal is read from the envelope or enforced anywhere.
  • No partition key, consistent hash or single-active-consumer setting is configured.
  • No per-entity serialisation, ordering buffer or reordering window exists.
  • No causation chain is followed — the causation field is parsed and never used.
  • No out-of-order detection or compensation exists.

Factors that break ordering​

Prefetch above one. Quality of service is configured with a prefetch count defaulting to 5, so up to five deliveries can be outstanding at once.

Asynchronous concurrent handling. The consumer's received handler is asynchronous and is not serialised, so multiple deliveries can be in flight simultaneously, each in its own dependency-injection scope.

Variable processing time. Processing includes provider sends and bounded retry delays, so two events can complete in an order unrelated to their arrival order. An event that fails and retries takes far longer than one that succeeds immediately.

Requeue. A negatively acknowledged message is requeued and redelivered later, arriving after events that were published after it.

What is ordered​

Only one thing: delivery attempts for a single message are numbered sequentially by the dispatcher's loop and can be read back in order, because the attempts query orders by attempt number.

That is per-message ordering within one delivery run, not event ordering.

Practical consequence​

For the platform's current event set the impact is limited, because the resolver treats each event as independent and each produces its own notification. No handler reads prior state to decide what to send.

The risk appears where a family emits a sequence whose notifications imply an order — for example a ticket status change followed quickly by a resolution, or a self-submission followed by a manager review. Those notifications can be delivered out of sequence, and nothing detects or corrects it.

The staleness guard is the only time-related control, and it filters by absolute age rather than relative order.

Classification​

Not implemented.

Requires confirmation​

Whether any event family requires ordered processing, and whether per-entity serialisation is planned, require confirmation.

See Also​

Keywords​

  • Notification database
  • Ordering
  • Draft database documentation

Source References​

  • microservices/src/notification-service/Messaging/NotificationEventConsumer.cs
  • microservices/src/notification-service/Application/NotificationOptions.cs
  • microservices/src/notification-service/Application/NotificationDispatcher.cs
  • microservices/src/notification-service/Messaging/NotificationEventEnvelope.cs

Revision Information​

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