The brief
Schedule one-off and recurring jobs across a fleet of workers. Your design should meet these requirements:
- Clients can submit delayed and recurring tasks.
- Eligible tasks are dispatched to available workers.
- Worker crashes and retries do not silently lose scheduled work.
Scale to design for
Clients submit delayed and recurring (cron) tasks; millions scheduled per day; tasks must not be lost and should run close to their scheduled time.
State these assumptions out loud in the interview, then let them drive your choices: they decide what needs caching, sharding or asynchronous processing.
Before you start
You'll get more out of this round if you're comfortable with:
- Delayed and cron scheduling
- Leases and heartbeats
- At-least-once delivery
- Retries and dead-letter queues
Questions an interviewer may ask
Expect follow-ups like these once your high-level design is on the board. Have an answer, and a reason, for each:
- What happens if a worker crashes halfway through?
- How do two scheduler nodes avoid dispatching the same task?
- How do you handle a backlog after an outage?
- How are retries and backoff configured?
Common mistakes to avoid
- A single scheduler node
- Scanning the whole table each tick
- No leases so crashed tasks vanish
- Assuming exactly-once
- Clock-skew issues between schedulers
Concepts this round covers
- Time partitioning
- Leases and retries
- At-least-once execution
- Distributed systems
What a complete answer covers
A schedule store and dispatcher design, worker lease/retry semantics, and explicit delivery and idempotency guarantees.
There is no single correct design. A strong answer meets the requirements at the stated scale and explains the trade-offs behind each choice. New to the format? Read how to prepare for a system design interview.