E-commerce order processing implemented twice: once as a hand-rolled pipeline, once as a Temporal workflow. The point is the diff between them.
check inventory -> process payment -> reserve inventory -> ship -> notify customer
Any step can fail. In traditional_implementation.py that means bespoke retry loops, manual state tracking, and compensation logic that has to be kept in sync by hand. In temporal_workflows.py the same pipeline becomes OrderProcessingWorkflow: each step is an activity with a RetryPolicy, state is persisted after every activity, and a crashed worker resumes exactly where it stopped.
What the Temporal version shows:
- Automatic state persistence and recovery
- Per-activity retry policies with exponential backoff
- Activity timeouts and heartbeats
- Saga-style compensation (
rollback_payment,rollback_inventory) when a later step fails OrderApprovalWorkflow: a long-running workflow that waits on a human signal
| File | Purpose |
|---|---|
traditional_implementation.py |
Baseline pipeline without a workflow engine |
temporal_activities.py |
Activity definitions (OrderProcessingActivities) |
temporal_workflows.py |
OrderProcessingWorkflow, OrderApprovalWorkflow |
temporal_worker.py |
Worker that registers workflows and activities |
temporal_client.py / simple_temporal_client.py |
Start workflows and query results |
*_fixed.py |
Standalone variants that run without the package-relative imports |
pip install temporalio
temporal server start-dev # local Temporal server + UI on :8233
python temporal_worker_fixed.py # terminal 1
python temporal_client_fixed.py # terminal 2Kill the worker mid-order and restart it: the workflow picks up from the last completed activity. Open http://localhost:8233 to watch the event history.
A walkthrough deck is in Temporal Demo_ E-commerce Order Processing x Arsh - README.pdf.