EASYwalkthrough
Tasks vs Workflows: Where the Scheduler Stops
"Run this at 9am" and "run A, then B and C in parallel, then D if C succeeded" look like siblings and are different species. The scheduler owns the first: time-triggered, single-shot execution with retries.
Drawing this boundary crisply is a scope decision that strengthens the design rather than shrinking it. What the boundary buys: the scheduler's state per task stays tiny and terminal (pending -> fired -> succeeded/failed/dead-lettered), so 10B pending tasks fit in 2 TB; a workflow engine's state per execution is a living graph (which steps done, what outputs, waiting on what) that must survive weeks and support queries like "resume from step 3": a different storage problem, a different failure model, a different product.
“The second is a workflow: a DAG of dependent steps with data passing between them, branch conditions, human approvals, and completion semantics: the domain of Airflow, Temporal, Netflix Conductor, and Step Functions.”
The relationship is layered, not competitive: workflow engines are the scheduler's best customers: Airflow needs "wake me at 9am" to start a DAG run; Temporal needs "fire this timer in 30 days" for durable sleeps: and building those timers is exactly this topic. Meanwhile the scheduler quietly supports one workflow-ish feature without becoming an engine: task chaining: a completed task may schedule a successor (retry-as-reschedule already does this): which covers "then" without touching "if", "join", or "wait for input".
The interview utility of the boundary is defensive precision: when the interviewer extends the problem ("now support dependencies"), the strong answer is not to bolt DAG fields onto the task row: it is to name the layering: the scheduler fires triggers; an orchestrator consumes them: and discuss which side each new requirement belongs to. What if the interviewer asks: could you build the workflow engine on this scheduler?
Yes, and that is the point: durable timers plus at-least-once firing plus idempotent handlers are exactly the primitives Temporal-class systems consume: this topic is the floor those systems stand on.
Related concepts