1
Idempotency
Processing the same command more than once produces one intended economic result.
Lesson · Algorithmic and Automated Trading
Reliability, Idempotency, Retries, and Recovery
Design duplicate-safe commands, bounded retries, durable state, reconciliation, and restart behavior for uncertain networks and asynchronous broker updates.
Core concepts
What to understand
Keep the boundaries, state, and authority explicit.
2
Bounded retry
Retry only eligible failures with backoff, limits, and the same command identity.
3
Reconciliation
Compare internal state with broker state and repair differences through controlled rules.
Interactive lab
Duplicate Delivery and Recovery Lab
Inject timeouts, duplicate events, crashes, and delayed broker updates. Toggle idempotency and reconciliation.
Duplicate Delivery and Recovery Lab
Deterministic synthetic educational data · no broker or live-market connection
SYSTEM MODEL
Process
Recover from durable facts
Do not infer execution state only from a failed network call.
Persist
Store command identity and intent before external side effects.
Attempt
Use bounded retry with the same idempotency key.
Reconcile
Query authoritative external state after uncertainty or restart.
Knowledge check
Check your understanding
Select one answer for each question. Feedback appears immediately, and a wrong choice is answered on its own terms before the rule is restated.
1. A retry should normally reuse:
The stable identity allows duplicate attempts to resolve to one action.
2. After a crash, recovery should begin from:
Persistent facts reveal which transitions may be incomplete.
3. Unlimited retries can create:
Retries must be bounded and aware of side effects.
4. The submit times out after the send. The client retries 3 times, each time with a new client order ID. How many orders can the broker hold for that one intent?
1 original + 3 retries with fresh identities = up to 4 orders. With the same key on every attempt the broker recognises one intent and holds one.
Practical rules
- Use stable command and client order IDs.
- Persist before publishing or calling external systems.
- Reconcile after timeout, restart, or status conflict.
Common mistakes
- Creating a new order ID on every retry.
- Treating HTTP errors as definitive broker rejection.
- Restarting without checking open external orders.
References
Official reading
These sources cover algorithmic controls, market access, broker APIs, system operations, or security.
Alpaca · Working with Orders
Official example of submitting orders and receiving asynchronous order-status updates.
FINRA · Regulatory Notice 15-09
Official guidance on supervision, testing, controls, documentation, and monitoring for algorithmic trading strategies.