Overview

Strategy workers (virtufin-strategies) decide trades from market data; executor workers (virtufin-execution-engines) place or simulate them -- neither's docs site is published yet, so not linked here. Both consume market data as an input, but neither maintains it -- raw exchange feeds (WebSocket deltas, REST snapshots) need to be turned into a coherent, queryable state (a live order book, a candle series, ...) before anything downstream can use it reliably. That's this repo's job.

Why a separate repo

WebSocketManager (the generic outbound WS-to-Dapr bridge every exchange connection goes through) is deliberately exchange- and domain-agnostic -- it forwards raw frames verbatim, with zero Binance-specific (or order-book-specific) logic. The actual "turn a stream of raw exchange frames into a correct, gap-resilient order book" logic needs a real home with its own state machine, tests, and deploy story -- a WorkManager worker, not something bolted onto the generic bridge.

Design pattern: one instance, many pairs

Unlike the strategy/executor workers in the sibling repos (which bind one instance to one scenario, explicit topics, no wildcard), a market-data worker here may deliberately track many pairs per instance when spinning up one instance per pair would be operationally heavy (see BinanceOrderBook's own page for the concrete tradeoff that drove this). The worker's output -- per-pair state keys and notification topics -- still follows the pubsub-topics spec's per-pair pattern exactly; only the input side may deliberately stay flat/shared when that better matches the upstream feed's actual shape.