How the interviewer opens it
“Design a platform that runs multistep workflows for days or months. It must recover from failures and support retries, timers, cancellation, and compensating actions.”
The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.
What to clarify first
- Workflow definitions
- Scale and workload
- Read and write mix
- Lifetime and data
- Latency
- Consistency and availability
- Durability
- External actions
- Cancellation
- Exclusions
The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.
Scope of a strong answer
Core requirements
- Start and inspect workflows with step dependencies.
- Execute steps with retries and durable timers.
- Recover progress after service or worker failures.
- Cancel workflows and execute declared compensating actions.
Usually out of scope
- Build a visual workflow editor.
- Execute arbitrary user code inside the workflow coordinator.
- Build external business services.
- Provide automatic failover across regions.
What interviewers ask about
- Progress after a worker failure
- A failure can separate external execution from durable progress. The engine must preserve one workflow state without assuming one task execution.
- External actions after a timeout
- The engine cannot atomically commit with an unrelated external service. A timeout does not reveal whether the external action succeeded.
- Timers after an outage
- Timers can outlive every server process. An outage can synchronize many deadlines and overwhelm normal work.
- Cancellation after partial success
- Cancellation races with task claims and external effects. Compensation must respect dependencies without pretending that completed business actions form a database transaction.
Common mistakes
- The design treats a queue as the complete record of workflow progress.
- The design claims exactly-once external effects because workers use leases.
- The design holds a database transaction open during an external call.
- The design derives peak step demand from workflow starts or average backlog from a p99 latency target.
- The design separates cancellation checks from task claims and ignores existing external effects.
- The design treats compensation as an automatic rollback without dependency rules or failure states.
The bar by level
- Senior (L5/E5)
- Traces failures across commits, dispatch, and external calls. Defines cancellation claim boundaries, uncertain-result recovery, and durable compensation order. Handles stale workers and overdue timers.
- Staff (L6+/E6+)
- States invariants and identifies each commit boundary. Separates steady load, burst capacity, and recovery demand. Defines operator procedures, partition boundaries, version compatibility, and regional recovery limits.