VisualHFT: The Architecture (interactive)

System Architecture: The Three Tiers

1. Presentation Layer (WPF)

The user-facing GUI, built with a strict MVVM pattern. Views (`.xaml`) are decoupled from logic (`ViewModels`), with data binding automated by Fody for clean, maintainable code.

2. Core Services Engine

The central nervous system. Manages the plugin lifecycle (`PluginManager`) and orchestrates data flow via a high-speed, in-memory Pub/Sub data bus (`Helper` classes).

3. Plugin Ecosystem

Dynamically loaded DLLs that extend functionality. `Data Retrievers` connect to external sources, while `Studies` perform complex, real-time analytics.

Real-Time Data Flow: The Pub/Sub Bus

Data flows unidirectionally from producers to consumers via a decoupled, event-driven bus implemented with singleton `Helper` classes. This ensures modularity and real-time responsiveness.

🔌

Producer

Data Retriever Plugin

→

🚌

Data Bus

`Helper` Class

→

📈

Consumers

UI & Study Plugins

Core Engine: High-Performance Engineering

Concurrency: `BlockingCollection<T>`

The system uses `BlockingCollection<T>` for its core producer-consumer queue. This provides an efficient, thread-safe mechanism for passing data from Data Retriever threads to consumer threads without manual locking, eliminating contention and reducing CPU overhead.

Memory Management: Custom Object Pools

To minimize Garbage Collector (GC) pressure and prevent unpredictable latency spikes, the platform implements custom object pools. Frequently used objects like `Trade` and `OrderBookUpdate` are recycled instead of being newly allocated, dramatically reducing memory churn.

Optimized LOB Data Structure

The Limit Order Book is implemented with a combination of data structures to achieve optimal time complexity for all critical operations.

1. Price Levels: `SortedDictionary<decimal, IOrderBookLevel>`

// O(log M) for level lookups

2. Orders at Price: `LinkedList<Order>`

// O(1) for FIFO additions/removals

3. Direct Order Lookup: `Dictionary<string, Order>`

// O(1) for cancellations/updates

The Plugin Ecosystem: A Framework for Extensibility

The `PluginManager` orchestrates the entire ecosystem. At startup, it scans a `/plugins` directory, uses reflection to find all types implementing `IPlugin`, and manages their lifecycle (`Initialize`, `Start`, `Stop`).

Data Retriever Plugin

Connects to a data source (e.g., FIX, WebSocket), parses the native format, and publishes standardized `Model` objects to the data bus.

Study Plugin

Subscribes to data from the bus, performs calculations (e.g., VPIN, Imbalance) in a separate thread, and publishes results back to the bus.

Anatomy of a Study: VPIN Implementation

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

1

Subscribe to `OnTrade` event from `HelperTrade` data bus.

2

Classify incoming trade as Buy/Sell (e.g., using Tick Rule).

3

Add classified volume to the current Volume Bucket.

4

If bucket is full: calculate imbalance, add to rolling window (queue).

5

Calculate new VPIN value from the rolling window.

6

Publish VPIN value to the data bus for UI consumption.

Technology Stack & Key Dependencies

Core Stack

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

Dependency Licensing

Key dependencies have licensing terms with significant implications for enterprise adoption.