Event-Driven Jobs

When someone creates a Hop link, Hop also fetches the target page to read its title and check it against a malware list. Done inside the request, that can take four seconds while the user watches a spinner. None of that work needs to finish before the user gets their short code. It just needs to happen.

The rule

Something happened → drop a message → a worker does the slow part.

A background job is work done outside the user's request. An event-driven job starts because something happened:

1. The request does only the essential part — save the link — and publishes an event, a small message such as link_created {id: 8812}, onto a queue.
2. The request returns to the user immediately.
3. A separate worker process takes messages from the queue and does the slow part.

Other events that suit this pattern: a user signs up (send a welcome email), a file is uploaded (make a thumbnail), an order is paid (start shipping).

Workers bring two useful properties. If work piles up, add more workers. If a worker crashes mid-job, the message stays on the queue and another worker retries it. That last point means a job may run twice, so jobs should be safe to repeat: "set status to safe" is fine to do twice; "add 1 to the count" is not.

The shortcut

For each step in a request, ask: "Does the user need this result before they can continue?" Yes → keep it in the request. No → make it an event and a job.

The trap is forgetting the half-finished state. Between "saved" and "scanned", what does Hop do if someone clicks the link? Decide it explicitly — here, show a short "checking this link" page.

Drills

Answer fast — trust the rule.

Remember

• Something happened → drop a message → a worker does the slow part.
• Shortcut: "does the user need this before continuing?" No → make it a job.
• Trap: forgetting the half-finished state, and jobs that are unsafe to run twice.