The operating problem
Trading systems do not fail along neat module boundaries. An exchange stream can lag while REST calls succeed. An order can be accepted while local state remains stale. A retry can protect delivery and still duplicate intent.
The engineering task is to make those transitions visible, bounded, and recoverable without pretending the exchange is deterministic.
Exchange boundary
The connector is treated as an unreliable external system. Authentication, request limits, WebSocket sequencing, acknowledgements, fills, and reconciliation are separate concerns with explicit failure paths.
Execution boundary
Order intent and exchange state are not assumed to be identical. Lifecycle transitions, idempotency rules, and recovery checks are designed before convenience abstractions.
Risk boundary
Risk checks belong before order emission. The design separates hard constraints from strategy decisions and keeps rejection reasons observable to operators.
Disclosure boundary
No returns, latency figures, line counts, or production-readiness claims are published without a reproducible evidence package. Selected technical detail can be reviewed under an NDA when it is relevant to a scoped engagement.