What you will learn
- Kill switch
- Restart safety
- Backup and restore
- Incident review
Kill switch
Recovery begins by identifying what state is authoritative and what local information may be stale. Retrieve current orders, positions and recent executions before replaying pending work.
Restart safety
Use stable identities and idempotent handling for repeated messages. A restart can redeliver events or leave a request outcome uncertain. Processing the same execution twice must not double its accounting effect.
Backup and restore
Restore dependencies in an order that respects their relationships. Starting decision logic before required data or account reconciliation is ready can create invalid actions even when every process eventually becomes healthy.
Incident review
Document rollback and forward-recovery choices. Rolling back software does not roll back market events. The system must reconcile actual account state with whichever behavior version is restored.
Worked example
A restart reloads a queued order request whose earlier execution succeeded but was not acknowledged locally. Blind replay can duplicate exposure; recovery must first establish the remote outcome.
Try it yourself
Describe a startup sequence that handles this uncertainty and define the evidence required before new entries are enabled.
Show the worked solution
Load persisted control state, connect required services, reconcile remote orders and fills against stable identities, resolve uncertain requests and verify data freshness. Enable dependent behavior only under the documented operating decision.
Apply this to your course project
Run an incident drill with reconciliation and a documented shutdown.
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.