Архитектура событийной шины

Обзор

Сервисы Barfinex обмениваются типизированными и проверяемыми событиями. Это помогает сохранять продуктовый конвейер наблюдаемым, не превращая публичный сайт во внутренний справочник рантайма.

События связывают основные этапы:

• Provider публикует нормализованные рыночные обновления.
• Detector формирует контекст сигналов.
• Advisor записывает детерминированное policy-решение ADMIT или REJECT и его неизменяемый basis.
• Inspector записывает решения по риску и результаты исполнения.
• Studio наблюдает поток через API и поверхности реального времени, которыми владеет Provider.

Зачем это нужно

Событийная архитектура помогает отвечать на практические вопросы:

• Какой сигнал запустил проверку решения?
• Почему Advisor допустил или отклонил его?
• Какое правило риска применил Inspector?
• Что видел пользовательский интерфейс в этот момент?

Публичная граница

Точные названия каналов, реализация очередей, replay-настройки, внутренние библиотеки, порты и переменные окружения являются деталями внутреннего рантайма. Публичные клиенты должны использовать Provider API, Provider WebSocket поверхности и документированные каталоги событий.

Дальше

• Архитектура Barfinex
• Provider API
• Конвейер сигналов