Building a Multi-Broker Trading System in Rust

Recommended architecture

Use a layered design: provider clients at the edge, a normalization boundary for instruments and events, an order management system, a risk engine, an execution kernel, and durable audit storage. Provider selection belongs to a capability and entitlement layer, not to business logic that guesses from a broker name.

Provider API → Adapter → Canonical contracts → OMS → Risk → Execution → Reconciliation

Rust design choices

Use typed enums for order states, environments, sides, order types, and failure classes. Keep provider I/O asynchronous, but make the decision and risk path deterministic. Use cancellation-safe tasks, bounded channels, monotonic event sequence checks, and durable identifiers for every outbound request.

Failure modes to design first

• Timeout after the provider accepted an order.
• WebSocket disconnect or sequence gaps.
• Symbol ambiguity across venues.
• Partial fills and fee currency differences.
• Position drift between local state and an account snapshot.

Production checklist

Persist the original provider, client instance, account, environment, native symbol, client order ID, request revision, and evidence used for the decision. If an execution result is unknown, query the original identity and reconcile before considering any retry.