---
id: ADR-PFM-NOT-004
title: The Queue Holds Only Work and SQS Owns Every Retry
product_area: platform
module: notifications
revision: 1
status: proposed
design_intent: confirmed
source_sha:
  services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1
  react-console: baf6dae382d6f41dce976c7f848667ccc37e076f
decision: Dispatchers publish pending rows to SQS and remove accepted rows; consumers retain outcomes
  and SQS supplies receive-based retries.
constrains:
- SVC-PFM-NOT-notifications
- SVC-PFM-NOT-communications
- WF-PFM-NOT-002
- WF-PFM-NOT-003
- WF-PFM-NOT-005
- WF-PFM-NOT-010
- WF-PFM-NOT-011
origin: Andrew 2026-10-10, the queued-work standard, services-platform:docs/queued-work.md#1. A queue
  table holds only work to be done
alternatives:
- option: Status and attempt columns on the queue row, polled by a worker
  why_not: Database polling with retry status duplicates the queue’s retry and dead-letter mechanisms.
- option: A durable job per send
  why_not: A durable job for every send adds an orchestration layer the adopted queued-work standard replaces.
consequences:
- Sending normally has eight receives with exponential backoff, then a dead-letter outcome for unresolved
  work.
- A request can exhaust receives before its retained History record exists.
- Attempt records explain completed provider activity rather than schedule future retries.
supersedes: []
evidence:
- 'services-platform at ad3f6a65: docs/queued-work.md §1 to §4 and §8; docs/communications/architecture.md
  §18; docs/notifications.md §6.'
---
# The Queue Holds Only Work and SQS Owns Every Retry

## Context

Queued delivery needs bounded retries and observable failure without a second scheduling system in the database.

## Decision

Dispatchers publish pending rows to SQS and remove accepted rows; consumers retain outcomes and SQS supplies receive-based retries.

## Alternatives Considered

Database polling with retry status duplicates the queue’s retry and dead-letter mechanisms. A durable job for every send adds an orchestration layer the adopted queued-work standard replaces.

## Consequences

Sending normally has eight receives with exponential backoff, then a dead-letter outcome for unresolved work. A request can exhaust receives before its retained History record exists. Attempt records explain completed provider activity rather than schedule future retries.