Design interviews / Intermediate / 6 min
Design a job scheduler
Workers claim jobs with leases. Crash one and the job is retried; make the lease too short and jobs run twice.
Start the simulation → Change the load, break a part, watch what happens. Free, no sign-up.
In short
- What it is
- A job scheduler stores jobs with a due time; workers claim due jobs with a lease, run them, and mark them done.
- Why it matters
- Emails, reports, billing runs and retries must happen even when individual workers crash or restart.
- The trade-off
- Short leases recover fast from crashes but re-run slow jobs; long leases are safe but leave work stuck for longer, so jobs must be idempotent.
- Say it in an interview
- "Jobs in a table, claimed with SELECT … FOR UPDATE SKIP LOCKED and a lease the worker renews; exponential backoff and a dead-letter queue after N tries."
Check yourself
Why does a worker take a lease on a job instead of just marking it "taken"?
Answer: If the worker dies, the lease expires and another worker can retry the job. A plain "taken" flag stays forever when its owner crashes; a lease frees the job automatically.
The lease is shorter than the time a job takes. What happens?
Answer: The job is handed out again while the first worker is still running it, so it runs twice. The scheduler assumes the worker died. Make leases longer than the slowest job, renew them while working, and make jobs idempotent.
What is a dead-letter list for?
Answer: Jobs that failed too many times, kept aside for a person to inspect. After a set number of attempts, retrying again only wastes work; the job is parked for debugging.
More in design interviews
- Design a URL shortener
- Design a notification system
- Design WhatsApp: ticks, offline inboxes and retries
- Design Instagram: photos through a CDN
- Design YouTube: upload, transcode, publish
- Design Netflix: adaptive bitrate streaming
- Design Uber: finding the nearest driver
- Design Google Maps: routes and live traffic