What you will learn
- Determinism
- Idempotent actions
- Versioned configuration
- Reproducible builds
Determinism
Implementation should use small components with explicit interfaces. Data preparation, decision logic, risk calculation and execution adaptation can then be checked separately while preserving end-to-end behavior.
Idempotent actions
Event handling must be deterministic under recorded inputs. External calls, current clock reads and random values should be isolated or injected so replay can reproduce the decision path.
Versioned configuration
Persistence should capture the state needed for recovery, not merely the final chart output. Record decisions, identifiers and configuration references so a restart can distinguish completed work from uncertain work.
Reproducible builds
Concurrency can create duplicate or conflicting actions if two processes observe the same old state. Use appropriate serialization, identity and transaction boundaries for the environment. A local in-memory flag may not protect multiple workers.
Worked example
Two workers both see no order and each submits one. Each local check was true, but the combined system duplicates exposure because the decision and submission were not coordinated.
Try it yourself
Describe a design that prevents this race without assuming only one process will ever run.
Show the worked solution
Use a shared serialization or transactional claim keyed to the decision identity, with idempotent execution handling and recovery records. Verify state again where required and test multiple workers, not only a single-threaded path.
Apply this to your course project
Build a demo strategy with unit, replay and failure-path tests.
Keep the calculation inputs, assumptions and decisions with your work. Practical exercises are self-reviewed; the scored knowledge checks assess the questions shown, not an independent certification of practical competence.