Event Bus Architecture

Overview

Barfinex services communicate through typed, auditable events. This keeps the pipeline observable without turning the public website into an internal runtime manual.

Events connect the major stages:

• Provider publishes normalized market and account updates.
• Detector produces signal context.
• Advisor records a deterministic ADMIT or REJECT policy decision and its immutable basis.
• Inspector records risk decisions and execution outcomes.
• Studio observes the flow through Provider-owned APIs and real-time surfaces.

Why it matters

The event architecture lets Barfinex answer practical questions:

• Which signal started this decision?
• Why did Advisor admit or reject it?
• Which risk rule was applied by Inspector?
• What did the user-facing terminal see at the time?

Public boundary

Exact channel names, queue implementation, replay settings, internal libraries, ports, and env variables are internal runtime details. Public clients should use Provider API, Provider WebSocket surfaces, and documented event catalogs.

Next steps

• Barfinex architecture
• Provider API reference
• Signal pipeline