Message Queue
A message queue holds work or messages until a consumer can handle them. Producers and consumers can run at different times and speeds.
Another example
Checkout writes order 984 and an outbox record in one transaction. A relay then sends “generate receipt” to a durable queue. Three workers confirm it only after saving the PDF and retry short storage failures with backoff. A message that always fails goes to a dead-letter queue with its correlation ID.
Main parts
- 01Producer and message
- 02Durable queue and delivery
- 03Consumer acknowledgement and failure path
Use it when
Use a queue to handle traffic bursts, separate slow work, retry short failures, or share tasks. Define exactly how delivery works.
Do not use it when
Do not add a queue when an immediate reply is required. Also avoid it without idempotent consumers, backlog limits, observability, and a plan for messages that always fail.
Name used in code
durable queue + delivery/ack policy + idempotent consumer + retry/DLQ Before you ship
Check contracts and invariants, authorization, and input limits. Test retries, one-time effects, timeouts, and partial failures. Verify data integrity, compatibility, monitoring, recovery, and rollback.
Outcome: Design or review Message Queue for this system while keeping data correct, secure, and easy to operate. User context: Checkout writes order 984 and an outbox record in one transaction. A relay then sends “generate receipt” to a durable queue. Three workers confirm it only after saving the PDF and retry short storage failures with backoff. A message that always fails goes to a dead-letter queue with its correlation ID. Technical concept or control: Message Queue. Why it fits: Use a queue to handle traffic bursts, separate slow work, retry short failures, or share tasks. Define exactly how delivery works. Do not use it when: Do not add a queue when an immediate reply is required. Also avoid it without idempotent consumers, backlog limits, observability, and a plan for messages that always fail. Engineering requirements: Define inputs, outputs, contracts, and rules that must always hold. Set authorization and input checks. Define failures, timeouts, retries, one-time effects, data moves, and compatibility limits. Operations: Add useful signals and logs that hide sensitive data. Set capacity limits and write an operator guide. Test recovery and rollback. Acceptance criteria: Contract and failure-path tests pass. Data and authorization rules still hold during retries and partial failures. Check performance limits, monitoring, recovery, and rollback. Evidence and limits (evidence boundary): No single official standard controls the whole term. Its meaning may change across teams, platforms, or frameworks. Unknowns to confirm: Where the code runs, data stores, traffic shape, consistency needs, and the security boundary. Also confirm the compatibility period, service goals, and rollback limits.
Check this request
Review the current use of Message Queue. Definition: A message queue holds work or messages until a consumer can handle them. Producers and consumers can run at different times and speeds. Release checks: Check contracts and invariants, authorization, and input limits. Test retries, one-time effects, timeouts, and partial failures. Verify data integrity, compatibility, monitoring, recovery, and rollback. Before changing code, report the evidence you found, gaps, severity, and the smallest safe fix.