Design order DAG execution with prerequisite state, atomic completion-versus-timeout decisions, idempotent refunds, durable recovery, and accurate status queries.
Process Orders Through a DAG with Completion and Timeout Refunds
Company: DoorDash
Role: Software Engineer
Category: System Design
Difficulty: medium
Interview Round: Onsite
Design and implement the core of an order-processing workflow represented as a DAG. Support order submission and status queries. An order that completes in time is finalized; an order that times out follows a refund path.
### Constraints & Assumptions
The source describes microservices and an example timeout/refund branch but gives no exact DAG or payment API. State the workflow and terminal-state rules before coding. A shared in-memory store can demonstrate one-process behavior; it does not by itself provide durable coordination across independent services.
### Clarifying Questions
When does the timeout start? What counts as completion? Can a late completion race with a refund? Are tasks and external effects idempotent? How is a failed workflow resumed after restart?
### What a Strong Answer Covers
Validated DAG definitions, per-order task state, prerequisite scheduling, an atomic terminal decision, effect identities, status reads, and recovery.
### Follow-up Questions
What happens if the completion and timeout handlers run concurrently? Can refunding fail? How do status queries distinguish refund requested from refund confirmed?
Overview: Design order DAG execution with prerequisite state, atomic completion-versus-timeout decisions, idempotent refunds, durable recovery, and accurate status queries.
Process Orders Through a DAG with Completion and Timeout Refunds
DoorDash
Sep 10, 2026
mediumSoftware EngineerOnsiteSystem Design
0
0
Design and implement the core of an order-processing workflow represented as a DAG. Support order submission and status queries. An order that completes in time is finalized; an order that times out follows a refund path.
Constraints & Assumptions
The source describes microservices and an example timeout/refund branch but gives no exact DAG or payment API. State the workflow and terminal-state rules before coding. A shared in-memory store can demonstrate one-process behavior; it does not by itself provide durable coordination across independent services.
Clarifying Questions Guidance
When does the timeout start? What counts as completion? Can a late completion race with a refund? Are tasks and external effects idempotent? How is a failed workflow resumed after restart?
What a Strong Answer Covers Guidance
Validated DAG definitions, per-order task state, prerequisite scheduling, an atomic terminal decision, effect identities, status reads, and recovery.
Follow-up Questions Guidance
What happens if the completion and timeout handlers run concurrently? Can refunding fail? How do status queries distinguish refund requested from refund confirmed?