Architecture Overview
Mercury is an event-driven trading engine. All inter-component communication flows through a single EventBus — a crossbeam bounded channel with a default capacity of 100,000 events.
Event flow
Market Feeds (WebSocket) → FeedManager → EventBus
│
┌────────────────────────────────┼──────────────────┐
▼ ▼ ▼
StrategyRunner OrderManager StorageManager
(on_book/on_trade) (submits orders (persists fills
│ via Gateway) to SQLite)
▼ │
Signal events Fill events
→ EventBus → EventBus
│
IpcServer
(/tmp/mercury.sock)
(broadcasts to TUI)
Key traits
| Trait | Crate | Purpose |
|---|---|---|
Strategy | mercury-strategy | Implement for new trading strategies. Methods: on_book, on_trade, on_fill, reset. |
ExchangeGateway | mercury-gateway | Implement for new exchanges. Async: submit_order, cancel_order, connect. |
FeedParser | mercury-market | Implement for new exchange WebSocket feeds. Methods: parse, ws_url, subscribe_message. |
Component lifecycle
Each long-running component is spawned as a tokio::spawn task:
- FeedManager — opens WebSocket connections, parses messages, publishes
BookUpdateandTradeevents. - StrategyRunner — subscribes to market events, calls strategy methods, publishes
Signalevents. - OrderManager — subscribes to
Signalevents, applies risk checks, submits orders via the gateway. - StorageManager — subscribes to
Fillevents and persists them to SQLite. - IpcServer — fans out events to connected TUI clients over a Unix socket.