Course lesson 35 · Managing Workflows with Durable Objects
System design & How we can use Durable Objects
The course introduces Durable Objects to decide when expensive destination-evaluation workflows should run. Instead of launching a workflow for every click, a stateful coordinator groups relevant clicks and schedules later work with an alarm. This places the scheduling and future subscription rules between the queue consumer and the evaluation workflow while keeping the redirect path fast.
Primary source: course video 35 · Supplied English subtitles · 00:07:58.
Understand the idea
- The web Worker uses tRPC and D1 for application data; the data-service Worker performs redirect handling and queue consumption.
- Workflows already handle evaluation execution, but manual dashboard triggering is not a product integration.
- A Durable Object combines application-defined state with code that can act on that state.
- Alarms schedule future execution, giving the coordinator a way to wake up and launch work later.
- Choosing the identity of each object determines which clicks share scheduling state and which remain independent.
What the course does
- Review the full path from the application’s stored links through Hono redirection and queue consumption.
- Identify browser rendering and AI as the comparatively expensive work that should not run on every click.
- Consider a rule that groups repeated clicks and performs one evaluation after a delay.
- Place a Durable Object between the queue handler and workflow creation.
- Keep the click context in persistent state and use an alarm to schedule the evaluation.
- Treat account tier and first-click behaviour as possible future business rules rather than completed features.
Watch for
- The conceptual explanation groups by destination URL; lesson 38’s actual implementation uses link ID plus destination URL.
- The subscription and first-click scheduling examples are design possibilities, not behaviour already implemented here.
- Added advice: an identity choice is a business decision—grouping too broadly can combine work that different links or accounts expect separately.
Recall before revealing
What responsibility belongs to the Durable Object here, and what remains in the workflow?
Reveal the explanation
The Durable Object decides when to start an evaluation using stored context and an alarm; the workflow performs the rendering, AI analysis, and persistence.
Try it
For 500 clicks to the same link and destination, describe the state and alarm you need to run one evaluation after a chosen delay.
Check your result
Your design keeps scheduling independent from evaluation execution and explains why the other 499 clicks do not require new workflows.
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:14 — Reviewing the application and redirect data flow
- 00:02:30 — Replacing manual workflow triggers
- 00:03:07 — Avoiding an evaluation on every click
- 00:05:22 — State plus alarms as the required capabilities
- 00:06:13 — Independent object instances and scheduling state
Companion primary documentation: What are Durable Objects?. For recorded API names, commands, limits, and prices, check the version you use.