Background jobs and schedules
Lesson 17 of 26 in the course “Vibe coding”. Free, with animations and a quiz.
The user doesn't wait
Example for this lesson: you run your school media site with a newsletter. Some jobs take long: emailing a thousand subscribers, compressing a video, building a report. If you do them while the person waits after a click, they stare at a spinner for minutes. The fix: a background job. The server instantly replies “got it” and does the work later. Jobs line up in a queue, like the cards in the figure, and a worker, a program that does the jobs, takes them one by one.
Cron: work on an alarm
Cron is running a job on a schedule, like an alarm clock. “Every day 9:00” in the figure: the server wakes up on its own and sends the reminder “article deadline today”. Schedules are written in short code like 0 9 * * *: minute 0, hour 9, and the stars mean “any day, any month, any weekday”. The trap: the time is often in UTC, world time, not yours. Check the docs.
Where to run it
Cloudflare: Cron Triggers run a Worker on a schedule. Vercel: Cron Jobs call your API's address at the set time. GitHub Actions (automation inside GitHub) can run a script on a schedule, but doesn't promise the exact minute. Inngest: a service for chains of steps, for example “signed up, remind them in three days”. Pick whatever your project already lives on. Check limits on the service's site.
Failed? Retry
A job can fail: the email service was down for a minute, the connection blinked. A good system doesn't give up, it retries after a pause: that's the “retry” arrow in the figure. In Inngest each step retries on its own, and steps already done don't run again. Ask the agent: “add retries with a pause and write to the log if the job still fails”. A log is a journal where the server records what happened.
Never charge twice
Retries are dangerous if the step already worked. Example: the subscription was charged, but the reply got lost on the way. A blind retry charges again. You need idempotency: repeating the same step gives the same result as running it once. How: each operation gets a unique ID, and the server first checks “is this already done?”. Webhooks in the figure can also arrive twice; same rule.
Check yourself
- Why make a thousand-email send a background job?
Correct answer: So the person doesn't wait for it all to send. The server replies “got it” right away and the emails go out later from the queue. The server is still doing the work. - What is cron?
Correct answer: Running a job on a schedule. Cron works like an alarm: “every day at 9:00”. Retrying after an error is a retry, and the event journal is the log. - What does idempotency mean for a payment step?
Correct answer: Repeating the step won't charge a second time. Errors always happen. Idempotency means a retry is safe: the server sees the operation's ID and doesn't do it twice.