Course lesson 24 · Working with Queues
Advanced Configuration: Delay, Retries & Dead Letter
This lesson extends queue operation with delayed delivery, retry configuration, and a dead-letter recovery path. The instructor deliberately breaks the consumer, observes failed events arriving in a paused dead-letter queue, restores the handler, and resumes delivery to recover the records into D1. It also distinguishes code organisation from deployment topology: producer and consumer may share one Worker or live in separate services.
Primary source: course video 24 · Supplied English subtitles · 00:13:04.
Understand the idea
- Producer delay postpones eligibility for delivery; the Twilio example waits before checking whether an SMS arrived.
- Retry count and retry delay express how much additional work the consumer should attempt after failure.
- A dead-letter queue provides a separate destination after the normal retry budget is exhausted.
- A Worker consuming two queues can inspect the batch’s queue name if different handling is required.
- Local queue state belongs to the development setup; separate local services do not automatically share the same queue state.
What the course does
- Review send options, including content representation and a delivery delay.
- Inspect consumer configuration for maximum retries and the delay between attempts.
- Create a staging dead-letter queue, pause delivery, and attach it to the main consumer configuration.
- Temporarily throw a test error, deploy, trigger clicks, and inspect messages collected in the dead-letter queue.
- Configure the data-service Worker to consume the dead-letter queue as well, with the demonstration retry setting.
- Restore and deploy the working handler before resuming delivery; confirm the D1 row count increases as queued failures are recovered.
Watch for
- Course caveat: repeated expensive AI or image operations can multiply costs, so retry policy must fit the operation.
- Added advice: a paused dead-letter queue still needs monitoring and a retention-aware recovery process.
- Added advice: replaying a partly completed handler can repeat earlier writes; recovery requires more than simply turning delivery back on.
Recall before revealing
Why fix the consumer before resuming a paused dead-letter queue?
Reveal the explanation
Resuming sends those failed events back to processing; if the original defect remains, recovery will fail again and may exhaust the new retry policy.
Try it
Write a five-step recovery checklist for a temporary database outage, from detecting dead-letter messages to confirming their records were saved.
Check your result
The checklist includes investigation, a verified fix, controlled replay, outcome checks, and duplicate-handling considerations.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Rewatch only what you need
Open this lesson in your original course library and seek to the times below. Videos are not hosted on this site.
- 00:01:23 — Local queue testing and separate-service caveats
- 00:04:31 — Producer delivery delay
- 00:06:23 — Retry settings
- 00:08:05 — Creating and pausing the dead-letter queue
- 00:11:58 — Recovering failed events after restoring the handler
Companion primary documentation: Queues delivery guarantees. For recorded API names, commands, limits, and prices, check the version you use.