Architecture overview of the system, it’s capabilities, and learnings of how they got there.
Most users shouldn’t use an exchange directly. They should speak w/ a brokerage.
2 big components: oms (order management system): user balances, risk checks, margin decisions matching engine: “order books” aka balancing the buy/sell ledger, also generates market data
hot path: balance check, order matching warm path: settlement auxiliary: market data feed
They have different trading system processes, depending on (for instance) the market [eth, usd].
After the trading system finishes it’s work, the market segmentation is merged into a single event stream.
—
Trading system logic isn’t complex.
- match incoming orders against resting orders (‘book’)
They try to model it as a deterministic state machine. Problems:
- datastructures: iteration may be different, depend on how big the underlying datastructures are.
- old input = old behavior. Meaning they need to use feature flags encoded into the state.
They use RAFT to help w/ fault tolernace.
- They use Aeron Cluster.
- Aeron Archive allows them to serialize the raftlog (requirement of protocol)
They use the resulting raft log for:
- debugging.
- traffic replay for CI/CD
---- they’re basically going too fast to take notes. :-/