At-least-once delivery removes a message only after processing finishes. A crash between processing and removal can therefore cause the same message to be processed again. section 8.2.3
Choose the guarantee by weighing duplicate work against lost data:
- Prefer at-least-once delivery when losing data is worse than processing an item twice. section 8.2.3
- Expect a poison message to create a restart-and-crash loop unless processing failures are monitored and handled. section 8.2.3 section 8.3
- Use a persistent queue when work must survive a program crash; available options include a database, RabbitMQ, AWS SQS, and Azure Storage Queues. section 8.3
Mail merge after a lost confirmation
If a mail server connection fails after sending but before confirmation, the sender cannot know whether the message arrived. Retrying risks a duplicate; skipping risks losing the message, so exactly-once delivery is usually unavailable. section 8.2.3



