Course lesson 22 · Working with Queues

Creating a Producer

One study unit · Read, recall, then practice · Original video 00:09:16

The redirect route becomes a queue producer: it packages each click with the destination and location context, then sends that event for later processing. The course uses the execution context’s waitUntil facility so waiting for the send does not delay the visitor’s redirect. This completes the connection between the fast HTTP path and the queue consumer built in the previous lesson.

Primary source: course video 22 · Supplied English subtitles · 00:09:16.

Understand the idea

The producer binding supplies send for one event and sendBatch for submitting multiple events efficiently.
A shared DataOps message type defines the event contract used by the producer.
The click payload includes link ID, account ID, destination, country, latitude, longitude, and a timestamp.
waitUntil keeps track of a background promise after the response, but it is not the same thing as durable queue acceptance.
The same Worker project can contain an HTTP producer and a queue consumer while the invocations remain separate.

What the course does

Add a producer binding in Wrangler, pointing to the same queue already used by the consumer.
Regenerate Cloudflare environment types so the queue binding becomes available to application code.
Construct a typed link-click message in the Hono redirect route using lookup results and request location data.
Pass the send promise to the request execution context’s waitUntil method.
Deploy, visit a valid smart-link ID, and confirm the browser still redirects to its destination.
Inspect consumer logs for the structured click payload rather than the earlier plain-text test message.

Watch for

The instructor explicitly notes that background sending is not completely fail-safe and questions its suitability for data that cannot be lost.
Added advice: successful redirection alone does not prove the queue accepted the event; inspect background-send failures.
Recorded subrequest limits and waitUntil time limits are platform details to verify before using them as design constraints.

Recall before revealing

At what point has a click become a durable queued event?

Reveal the explanation

After the queue has accepted the send; returning the redirect or starting a waitUntil promise is not itself that acknowledgement.

Try it

Trace each payload field back to its source: link lookup, selected destination, request location, or generated timestamp.

Check your result

You can explain why the consumer has enough context to process a click without repeating the redirect request.

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:00:38 — Capturing clicks without delaying redirects
00:02:03 — send and sendBatch
00:03:11 — Shared link-click message type
00:05:38 — Moving queue send into waitUntil
00:08:20 — Checking the received JSON event

Companion primary documentation: Queues delivery guarantees. For recorded API names, commands, limits, and prices, check the version you use.

← Previous Next →