Module 7 6 lessons 84 min
Background jobs
Placing an order now saves it, texts the customer and emails a PDF invoice, all while the customer waits. On a festival night the SMS provider slows to 3 seconds, and orders start timing out - though our servers and database are fine.
In this module
5 Read · 1 Lab
- 7.1Why the user shouldn't waitThe order is slow because of an SMS the customer didn't need yet. Which work must happen before the response, and which can happen after.Read10 min
- 7.2A queue in the database you haveA jobs table and a worker that polls it. Why two workers grab the same job, and how row locks and SKIP LOCKED stop it. Often all you need.Read12 min
- 7.3Queues and workersOur database is already the busiest part, so jobs move to a dedicated queue. Producers, workers, and a queue that absorbs the dinner spike.Read15 min
- 7.4When a job failsA slow SMS provider now holds up workers instead of customers, and the queue piles up. Timeouts, retries with backoff, acknowledgements, and idempotent workers - because a job can run twice. And a dead-letter queue for jobs that never succeed.Read14 min
- 7.5Proof: take the SMS out of the orderLoad-test orders with a slow SMS provider, then with a queue. Then kill a worker mid-refund and count the refunds, with and without an idempotency key.Read8 min
- 7.6Lab: Add a queue to the clinicSend the day-before appointment reminders through a queue and workers - every one on time, and none twice.Lab25 min