Overview¶
What Dyson is¶
Dyson is the application and runtime layer around Kuru trading strategies. It turns versioned configuration into live market-data publishers and strategy processes, carries live traffic over NATS, executes through Kuru adapters, and projects trading state to InfluxDB for operators.
Core capabilities¶
- Market-data bundles: a deployment selects a versioned bundle of venue publishers. One supervisor launches and stops the imported publisher processes together.
- Strategy processes: each strategy binary loads one deployment, builds the shared runtime, and owns its venue-specific composition.
- Serialized execution: lifecycle commands, market data, clocks, and venue events enter one mutable runtime path.
- Kuru execution: current adapters support Kuru orderbook and vault flows.
- Live operations: the control panel combines NATS status and events, InfluxDB projections, and public Kuru market data for one deployment.
- GitOps deployment: application images and cluster desired state are owned separately and promoted by immutable image digest.
Repository shape¶
| Area | Purpose |
|---|---|
crates/ |
Shared database, market-data, runtime, API, and venue code |
strategies/ |
Independently runnable strategy packages |
control-panel/ |
Next.js operator application |
external/ |
Pinned algo-trading and Kuru SDK submodules |
dyson-deployment |
Kubernetes, Argo CD, secrets integration, and platform desired state |
Why this architecture¶
Dyson separates configuration, live transport, strategy decisions, venue execution, analytical storage, and release state. A strategy can change its logic without owning NATS or process lifecycle, while deployment changes can promote an existing image without changing application code.
Continue with system architecture for ownership and data flow, or open a component guide for the part you are changing.