Deterministic workflows
Practice this question🔴 MUST KNOW · Architecture determines where uncertainty is allowed.
Overview
- A deterministic workflow follows explicitly coded transitions for given inputs and recorded external outcomes.
- It can call nondeterministic services, but its orchestration rules remain controlled.
- It is the natural extension of validation, transactions, and backend state machines you already know.
Why this matters
Critical processes require predictable enforcement, auditability, and recovery.
An everyday example
A checkout process always verifies stock and payment before confirming an order.
A technical example
validate → check ownership → calculate deductible → save claim → enqueue notification.
How it works
- Define states/rules
- Validate every transition
- Execute authorized activities
- Persist outcomes
- Retry or compensate according to policy.
Architecture and flow
Request → validate → check → calculate → execute → notify.
The insurance assistant example
Premium calculation, coverage rule evaluation, approval requirements, and claim submission are governed by code and authorized review.
When to use it
Known processes, money, permissions, deadlines, and regulated business decisions.
When to avoid it
Hardcoded branches can become impractical for open-ended language understanding; use a bounded model step there if needed.
Interview answer
“Deterministic workflows encode the allowed business process. External failures are handled explicitly rather than allowing a model to invent the next business rule.”
Benefits, trade-offs, and production considerations
- Deterministic does not mean failure-free: databases and networks still fail.
- Record external results, use idempotency, and test state transitions and compensation.