Temporal Take‑Home: Function Stubs Only (Python) with DB Read/Write Notes
Goal
Use Temporal’s open‑source SDK and dev server to orchestrate an Order Lifecycle. You will design the workflows and activities. This doc supplies function implementations that simulate failures and timeouts, plus assignment requirements. Your activities should call these functions and handle database persistence.
Why We Use Temporal
Trellis coordinates long-running, stateful operations where reliability and clear audit trails matter (e.g., multi-step data workflows, vendor calls, human approvals). Temporal gives us:
- Durability & fault tolerance. Workflow state is persisted, so workers can crash or be redeployed without losing progress. Retries, backoffs, and timeouts are first-class—not bolted on.
- Deterministic orchestration. We encode the control plane (timers, signals, child workflows, compensation) once; Temporal replays history to guarantee consistent decisions across retries and restarts.
- Idempotent side effects. Activities are retried safely; we implement idempotency keys in our own DB to make external calls (payments, notifications, writes) safe to repeat.
- Human-in-the-loop. Signals and timers make manual review/approvals and SLAs natural, without custom schedulers or cron drift.
- Observability by design. The event history is a truthful source for debugging, auditing, and support. We can expose live status and recent errors without inventing bespoke tracking.
These capabilities map directly onto Trellis’ needs: dependable automation across unreliable networks and third-party systems, clear visibility for operators, and safe recovery when anything fails.
Why an “Order” workflow (instead of Trellis’s per-service healthcare flows)
We picked an Order → Payment → Shipping model for the exercise because it’s simple and self-contained while still exercising the core Temporal primitives we care about in real work:
- Signals & timers: Manual review before payment is a realistic human gate with a deadline.
- Retries, timeouts, compensation: Payments and dispatch are classic side-effects that must be idempotent and safely retried.
- Child workflows & task-queue isolation: Shipping runs on its own queue, showing how we scale teams/services independently.
- End-to-end state & auditing: Orders, payments, and shipping events provide a clean domain to persist to SQL and query live status.
An order domain avoids domain-specific baggage and lets you focus on orchestration quality—determinism, resilience, and observability—exactly what we evaluate for Trellis’ production workflows.
What to Build (Domain Scenario)