6. Messaging and Asynchronous Work

Queues and events can decouple request intake from processing and smooth load, but they change the programming model. At-least-once delivery can produce duplicates, parallel consumers can change ordering, and failed messages can create infinite retry loops or growing backlogs. Design these behaviors before choosing a broker.

Evidence: S12, S13, S14

Checklist

• The reason for asynchronous processing is explicit: decoupling, load leveling, latency, resilience, or workflow.

• The required delivery guarantee is understood.

• Consumers are idempotent when redelivery is possible.

• Message ordering requirements are explicit and scoped, preferably by business key rather than global order.

• Poison messages have a dead-letter/quarantine path.

• Retry count and delay are bounded.

• Queue depth/backlog is monitored.

• Producer rate cannot grow indefinitely above safe consumer capacity without a response strategy.

• Large payload strategy is defined.

• Schema/version evolution is defined.

• Correlation IDs link messages to the originating business request.

• DB + broker publishing uses outbox or another justified reliable mechanism.

• Replay behavior is safe.

• Duplicate detection is helpful but does not replace idempotent processing.

Evidence: S12, S13, S14, S15, S56