Question presented to candidate:
"Design a distributed job scheduler, something like a cron service for the whole company. Teams register jobs that run once at a given time or on a cron schedule, millions of them. Every job must run on time, a run must not be lost if a machine dies, and a run must not happen twice by accident. How would you build it?"
What a strong answer should cover:
Separating definitions (the job and its schedule) from runs (one row per scheduled firing, with a unique run id such as job id plus scheduled time), stored durably in a database
How due jobs are found at scale: an index on next fire time, scanned by scheduler instances that each own a partition, with leader election or row claiming so one firing creates exactly one run row
Execution with leases (visibility timeouts), heartbeats and retries, and a fencing token so a worker that stalled and lost its lease cannot commit afterwards; delivery is at-least-once, so job handlers are idempotent keyed by run id
Policies a real scheduler needs: misfire handling after downtime (fire all, fire once, skip, or a deadline), overlap policy for long runs, retry with backoff and a dead-letter state
Capacity and hot spots: runs per second, the top-of-the-hour herd, and jitter to spread it; what breaks first at 10x
Clarifying questions expected:
How precise must start times be: within a second, or within a minute?
What does a job do: call an HTTP endpoint, put a message on a queue, or run a container? Who owns retries?
Is exactly-once required, or is at-least-once with idempotent handlers acceptable?
Code / implementation expected: Optional โ the example simulates unique run rows, leases with fencing tokens, a stalled worker being fenced off, misfire policies after an outage and jitter on a top-of-hour herd.
scheduler
queues
2
Try it yourself
Sketch your approach before you read the solution. That is what the interview tests.
Stuck? Get a hint.
A short nudge toward the approach. It will not give the answer away.
3
Solution
Target Audience: Engineers preparing for a system design round. You know what a database, a queue and a server are; leases, fencing and misfire policies are explained from zero.
Difficulty: Hard
Verified with: Node 22 and Python 3.12 (identical output). Kubernetes CronJob and PostgreSQL facts are cited inline, checked in October 2026.
How to read this doc: Plain language first, then ๐ Interview term: callouts with the vocabulary an interviewer expects. Every number in the deep dives comes from the example program, quoted in full in the Verified section. Queues themselves are covered in the distributed message queue design; a single-service job queue is covered in the Node.js job queue design. Th
The solution is hidden so you can try first
19 min read ยท 17 sections
4
Read the code
Distributed job scheduler: capacity, unique run rows, leases with fencing tokens, misfire policies and jitter