# Design a CI/CD Task Scheduler Design the scheduling core of a continuous-integration and continuous-delivery system. A pipeline is a directed acyclic graph of tasks. A task becomes runnable after all required predecessors succeed. Workers have capabilities, tasks request resources, and users need cancellation, retries, and visibility into progress. Focus on the task scheduler rather than source hosting or a particular build tool. Explain APIs, durable state, queueing, worker leasing, failure recovery, fairness, and how a deployment stage differs from an ordinary build task. ### Clarifying Questions to Ask - Are pipelines triggered manually, by commits, or on schedules? - Can the same logical task run more than once, and what is the idempotency key? - Which resources and worker capabilities constrain placement? - What retry policy is safe for builds versus deployments? - Is strict project fairness required when one tenant submits a large burst? ### What a Strong Answer Covers ```premium-lock What a Strong Answer Covers ``` ### Follow-up Questions - How would you schedule millions of short tasks without a database hot spot? - How would you prevent an expired worker from committing a stale deployment result? - How would you support fan-out, fan-in, and dynamically generated tasks? - Which operations must be transactional?