Skip to main content

Notification Retry Persistence

Summary​

Retry has no table of its own. Retry state is persisted as a counter on the message row plus one append-only attempt row per try. There is no retry queue, no scheduled backlog and no dead-letter table.

Audience​

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

Retry persistence​

What is persisted​

StateWhere it lives
Attempts made so farAttempts counter on the message row
Last failure reasonLastError on the message row, cleared on success
Per-attempt historyOne row per try in the attempts table
Terminal failureStatus set to failed on the message row
Stage transitionsAudit rows at the retried and delivery-failed stages

What is not persisted​

  • No retry schedule. Backoff delays are computed in memory by the retry policy and awaited in process. No next-attempt timestamp, due time or lease is stored.
  • No retry queue. No table holds messages awaiting a future attempt. A process restart mid-loop leaves the message in whatever state was last saved, with no record that further attempts were intended.
  • No dead-letter table. Configuration names a dead-letter exchange and queue, but the consumer declares its queue without dead-letter arguments and no dead-letter row is persisted anywhere.
  • No attempt lease or ownership. Nothing prevents two processes retrying the same message concurrently.

Manual retry​

The retry endpoint resets the message to pending, clears the last error, saves, and re-enters the same bounded loop. The attempt counter is overwritten by the new loop's attempt numbers rather than accumulated across invocations, so the counter reflects the most recent delivery run, not the lifetime total. The attempts table retains the full history.

Recovery posture​

Because failed messages persist with a failed status and are queryable, re-driving is possible — but it is manual and one message at a time. No reviewed code path re-drives the failed set automatically.

Classification​

Partial — attempt history is Implemented; scheduled retry, dead-letter persistence and automatic re-drive are Not implemented.

Requires confirmation​

Whether persisted retry scheduling and dead-letter storage are planned requires confirmation.

See Also​

Keywords​

  • Notification database
  • Retry Storage
  • Draft database documentation

Source References​

  • microservices/src/notification-service/Application/NotificationDispatcher.cs
  • microservices/src/notification-service/Application/RetryPolicy.cs
  • microservices/src/notification-service/Domain/NotificationEntities.cs
  • microservices/src/notification-service/Messaging/NotificationEventConsumer.cs
  • microservices/src/notification-service/Api/NotificationEndpoints.cs

Revision Information​

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