Subsystem 01
Market data ingestion
WebSocket feed parser with zero-copy JSON and binary decoding
Typical stack
Rust + Tokio + simd-json
Reference architecture
Low-latency crypto order execution engine in Rust
A Rust engine that ingests market depth, evaluates arbitrage signals and places orders, with no heap allocation on the hot path and a sub-millisecond internal latency target.
Design constraints
What the design has to hold to
Targets for the scenario this reference is sized for. A real engagement starts by replacing them with your own numbers.
- 01Internal order execution latency target: p99 under 500 µs
- 02No heap allocations in the market data processing loop
- 03Atomic pre-trade risk checks and maximum position limits
- 04Automatic WebSocket reconnection with sequence-gap recovery
Component topology
System components and technologies
Subsystems with separate responsibilities, clear contracts between them and storage that scales on its own. The stack named for each is typical, not mandatory.
Stack topology
Low-latency crypto order execution engine in Rust
Illustrative reference architecture
- 01
Market data ingestion
WebSocket feed parser with zero-copy JSON and binary decoding
Rust + Tokio + simd-json
- 02
Internal order book
In-memory L2/L3 book of live bids and asks
Lock-free ring buffers & B-trees
- 03
Risk management gate
Margin validation and kill-switch circuit breakers, checked in microseconds
Rust atomic operations
- 04
Execution gateway
Signed order placement over REST or WebSocket
Rust Hyper / custom TCP client
Subsystem 02
Internal order book
In-memory L2/L3 book of live bids and asks
Typical stack
Lock-free ring buffers & B-trees
Subsystem 03
Risk management gate
Margin validation and kill-switch circuit breakers, checked in microseconds
Typical stack
Rust atomic operations
Subsystem 04
Execution gateway
Signed order placement over REST or WebSocket
Typical stack
Rust Hyper / custom TCP client
Data lifecycle
End-to-end data flow
The exchange pushes an incremental order book diff; simd-json parses it into pre-allocated buffers.
The order book applies the diff, recalculates VWAP and evaluates strategy signals.
If a signal fires, the risk gate runs atomic checks (maximum position, open orders, drawdown limits) in microseconds.
The signed order goes out over a persistent HTTP/2 or WebSocket connection to the exchange's matching engine.
Fills update the internal position trackers and emit telemetry to ClickHouse.
Reliability and resilience
Failure modes and how each is contained
Failure mode 01
Exchange WebSocket packet loss
Mitigation
Detect sequence gaps, request a fresh L2 snapshot over REST and buffer live updates until it arrives.
Failure mode 02
Runaway algorithm positions
Mitigation
An independent kill switch and hard position caps reject any order above set limits, alongside exchange-side limits where offered.
Failure mode 03
Operating system scheduling jitter
Mitigation
Pin engine threads to dedicated CPU cores (isolcpus) and disable CPU frequency scaling.
Questions
What teams ask about this design
Rust gives C++-class performance with memory safety checked at compile time, and it has no garbage collector, so there are no collection pauses of the kind Go can introduce under load.
We run the engine in the same cloud region or colocation facility as the exchange's matching engine, confirmed with latency probes rather than assumed, and keep connections warm.
Planning a system like this?
Send us your requirements, expected load and budget. We'll reply within one business day with an honest read on the design, and on whether we're the right team to build it.