The decision
Email delivery is an external side effect. Store the intent to send before contacting the provider, and record attempts, availability time, lease ownership, and final state. A worker can retry after failures or reclaim a job whose previous worker stopped. The order should remain recoverable even when email is delayed.
A worked example
A purchase email job has a deterministic ID derived from the checkout session. The worker leases it, checks that the order is still eligible, and sends a link containing the same verified entitlement as the success page. A temporary provider failure returns the job to pending with backoff. After a bounded number of failures it enters a visible failed state for operator review.
How to put it into practice
- Use a worker lease so concurrent workers do not claim the same available row.
- Set a lease longer than the bounded provider request, and reclaim expired leases.
- Use a stable provider idempotency key when supported.
- Keep error records useful but free of customer email bodies, keys, and sensitive tokens.
A failure to plan for
A crash between provider acceptance and marking the job sent creates an uncertain outcome. Provider idempotency may help only within a documented time window. Do not claim permanent exactly-once delivery; retain an operator process for ambiguous jobs.
Try it on your project
Simulate a provider failure, run the worker, and inspect the pending retry. Simulate two workers and an expired lease. Check that successful purchase links preserve the session ID and that the worker never sends marketing to an unsubscribed person.
Keep the next step small
Use the free demand scorecard or planning tools to make your assumptions explicit. The $19 launch kit brings the blueprint and seven editable worksheets together.