VisualHFT: The Architecture (interactive)

System Architecture

1. Desktop host

The WPF application starts VisualHFT, hosts the dashboard, loads plugins, and owns the trigger-engine configuration.

2. Shared libraries

VisualHFT.Commons owns shared models, helpers, and plugin contracts. VisualHFT.Commons.WPF adds reusable WPF support on top of Commons.

3. Plugin assemblies

Connector plugins ingest venue data. Study plugins calculate live analytics. Both use the shared contracts and are discovered beside the application executable.

Market Data and Results

Connectors publish normalised order books, trades, providers, and symbols through their matching shared helpers. Dashboard view models and studies subscribe to those helpers. Studies emit BaseStudyModel results for live views and trigger evaluation.

🔌

Producer

Data Retriever Plugin

→

🚌

Shared Helpers

OrderBook, Trade, Provider, Symbol

→

📈

Consumers

Dashboard and study plugins

Core Engine: High-Performance Engineering

Callback ownership

Order-book and trade helpers invoke subscribers synchronously. A subscriber must return quickly and must not retain the mutable OrderBook from the callback.

Snapshot when work outlives the callback

A consumer that needs an independent book state can create an OrderBookSnapshot. It rents storage for copied book items and must be disposed after use.

Optimized LOB Data Structure

Order books are updated in place as market data arrives. Queues and snapshots are opt-in consumer choices, not a universal study implementation.

1. Incoming update: a connector updates a normalised OrderBook.

// connector code owns the venue-specific delta logic

2. Shared view: HelperOrderBook calls dashboard and study subscribers.

// callback work must remain short

3. Longer work: a consumer creates and later disposes an OrderBookSnapshot.

// snapshot and queue use are per-consumer decisions

The Plugin Ecosystem: A Framework for Extensibility

At startup, PluginManager scans the directory containing VisualHFT.exe, finds non-abstract exported types implementing IPlugin, and starts the applicable connector, study, or multi-study lifecycle.

Data Retriever Plugin

Connects to a venue, maps its native messages into normalised market models, and publishes those models through the matching shared helpers.

Study Plugin

Subscribes to shared data, calculates its metric, and sends BaseStudyModel output through AddCalculation(...) and OnCalculated.

Anatomy of a Study: VPIN Implementation

A VPINStudy plugin demonstrates the platform's analytical power. It is a stateful, event-driven component that processes raw trades into a microstructure indicator.

1

Subscribe to configured trade and order-book updates from HelperTrade and HelperOrderBook.

2

Classify a trade against the latest order-book midpoint, with the provider's buy or sell flag as fallback.

3

Add classified volume to the current Volume Bucket.

4

When a bucket is full, calculate its imbalance and add it to the fixed-size rolling window.

5

Calculate new VPIN value from the rolling window.

6

Emit the new VPIN value with AddCalculation(...), which raises OnCalculated for live views and triggers.

Technology Stack and Runtime Boundaries

Core Stack

  • Framework: .NET 10
  • Language: C#
  • UI: Windows Presentation Foundation (WPF)
  • Pattern: Model-View-ViewModel (MVVM)
  • Platform: Windows Only

Runtime boundaries

  • Commons: Shared models, helpers, and contracts with no WPF dependency.
  • Commons.WPF: Reusable WPF support that depends on Commons.
  • Plugins: Assemblies loaded into the desktop application's process from beside the executable.