Build a Refund Workflow Engine over an Outcome-Driven DAG

Extend an existing refund workflow engine whose nodes form a directed acyclic graph. A node performs work such as checking an order delay, issuing a refund, or notifying a customer; its outcome selects the next edge. Explain traversal and execution, then extend the design for partial refunds and an additional action such as cancellation. Address duplicate API calls and a workflow that is too slow for an interactive request. Finish by explaining the implementation's current state and showing an architecture diagram with labeled data paths. ### Constraints & Assumptions - The graph and starter interfaces are not supplied here; describe responsibilities without inventing their exact API. - Confirm whether an outcome selects one edge or several, how terminal nodes are represented, and whether joins exist. - Refund amounts, cancellation policy, and external-provider guarantees must be explicit. ### Clarifying Questions to Ask - What identifies one workflow run and one logical refund action? - Can a node be retried after an unknown outcome, and can the provider look up that action? - How are partial refunds constrained relative to earlier refunds on the order? ### Part 1 — Execute and Extend the Workflow Explain graph validation, outcome routing, persistent node state, and new action types. #### What This Part Should Cover - Reachability, termination, and unsupported graph shapes. - Separation of traversal from action handlers. - Explicit partial-refund and cancellation semantics. ### Part 2 — Recover and Respond Quickly Explain duplicate handling and asynchronous execution, then present the components and protocols in a diagram. #### What This Part Should Cover - Durable run/action identities and recovery after external effects. - A prompt acknowledgement distinct from refund completion. - Honest reporting of implemented, incomplete, and unverified behavior. ```hint Retrying a node is not the same as creating a new logical refund. Keep those identities separate. ``` ### What a Strong Answer Covers The engine should follow outcomes deterministically under an agreed graph contract, make external effects replay-safe, and expose progress without blocking the user on the entire graph. The final explanation must match the implementation rather than imply unfinished work is complete. ### Follow-up Questions - What if notification fails after a refund succeeds? - How would two partial-refund requests avoid exceeding the refundable amount? - What extra coordination would parallel branches and joins require?