Barfinex architecture — ecosystem and data flow

Overview

Barfinex is a modular ecosystem. Each component has a clear role: Provider connects to exchanges, Detector generates signals, Advisor helps with decisions, Inspector manages risk, and Studio gives you a single interface. This page explains how data flows between them and how to reason about your deployment.

High-level data flow

Exchange (Binance / Alpaca / …)
        │
        ▼
   [ Provider ]
   • Connects to the exchange (REST + WebSocket)
   • Publishes market data and order events to the event bus
   • Exposes REST API: accounts, orders, candles, connectors, app registry
   • WebSocket /ws — streams events from the bus to Studio
        │
        ▼
   [ Event bus ]  — single message backbone
   • Channels = event names (market data, signals, risk, decisions)
   • All components use the same bus
        │
   ┌────┴────┬────────────────┬────────────────┐
   ▼         ▼                ▼                ▼
[Detector] [Inspector]   [Advisor]    [Studio via /ws]
   │         │                │
   │         │                └── Subscribes to signals; publishes decisions
   │         │
   │         └── Monitors positions and risk; publishes risk events
   │
   └── Subscribes to market data and risk; publishes signals and position requests

What each component does

Provider

• Reads: Exchange (REST + WebSocket: tickers, order book, trades, candles, account, orders).
• Writes to the bus: All data-layer events (trades, order book, candles, account, orders, symbols, prices).
• Also: REST API for accounts, orders, candles, connectors, app registry; proxy to Advisor, Inspector, and Detector; WebSocket /ws streams the same events to the browser.

Provider is the single entry point for the frontend: one URL, one token, one WebSocket.

Detector

• Reads from the bus: Market data and account/order events from Provider, and risk events from Inspector.
• Writes to the bus: Trading signals and position requests (open, close, reduce, flip).
• Runs as a separate service: Its own process or container; connects to the event bus and registers with Provider so Studio can reach it via proxy.

Advisor

• Reads from the bus: New signals from Detector (and optional decision requests).
• Writes to the bus: Decision responses and context snapshots.
• Runs as a separate service: Registers with Provider as type advisor so Studio and other clients can call it through Provider.

Inspector

• Reads from the bus: All market and order events from Provider, and position requests from Detector.
• Writes to the bus: Risk events (limit breach, kill switch, etc.).
• Runs as a separate service: Executes orders and stops via Provider REST API, not through Detector. Registers with Provider as type inspector.

Studio (web app)

• Reads from: Provider only. REST via proxy to Advisor/Inspector/Detector; accounts, orders, candles from Provider. Real-time events via Provider WebSocket /ws.
• Does not connect directly to the event bus or to other services’ ports when using the recommended setup.

Default ports

App registry

Advisor, Inspector, and Detector register with Provider at startup:

• Endpoints: register, heartbeat, unregister.
• Result: Provider knows where to proxy requests and lists these apps in Studio. You use a single base URL and appKey to talk to each component.

For details on the API and proxy paths, see Provider API reference and Building with the API.