Venue Connectivity
Use this pattern when your firm needs a persistent session-based link to a single counterparty: a venue, exchange, ECN, prime broker, or client. One adapter owns the session, keeps it healthy, and routes messages between that counterparty and your internal systems.
The platform treats each session as a long-lived, stateful resource. A single active instance owns the session at any time. If the active instance stops responding, a standby instance takes over the session without losing messages.
You build this link with a session-based connector plugin that speaks the counterparty's protocol, such as the FIX plugin for a FIX session.
Inbound: Receive from a venue
Your firm connects outward to a counterparty that publishes messages back (execution reports, trade confirmations, market data). The adapter establishes the session, subscribes to the counterparty, and delivers received messages to an internal destination such as a Kafka topic.
| What the platform handles | What you configure |
|---|---|
| Session establishment and heartbeat monitoring | Counterparty connection details (host, port, session identifiers) |
| Automatic reconnection on transient failures | Message filtering and transformation rules |
| Sequence number tracking and gap recovery | Output format and internal destination |
| Failover to a standby instance | Deployment mode (Single Writer), chosen in the wizard. The replica count is set at deploy time by an administrator via Helm (adapter.replicaCount), not in the Portal. |
Outbound: Send to a venue
Your internal systems produce messages (such as orders) that need to reach a counterparty. The adapter reads from the internal source, formats each message for the counterparty's protocol, and delivers it over the session.
| What the platform handles | What you configure |
|---|---|
| Protocol formatting and session management | Internal source (e.g., a topic or upstream adapter) |
| Sequence number tracking on both sides of the session | Transformation rules that shape messages for the counterparty |
| Delivery acknowledgment | Counterparty connection details |
| Standby takeover of an in-flight session | Deployment mode (Single Writer), chosen in the wizard. The replica count is set at deploy time by an administrator via Helm (adapter.replicaCount), not in the Portal. |
Acceptor: Receive inbound connections
Instead of initiating the connection, the adapter listens on a port and waits for a counterparty to connect (useful when a client, prime broker, or upstream system is the initiator). The platform terminates the session, authenticates the counterparty by session identifiers, and routes inbound messages into your systems.
| What the platform handles | What you configure |
|---|---|
| Port binding and session acceptance | Listening port |
| Counterparty authentication via expected session identifiers | Expected session identifiers per counterparty |
| Inbound message routing through the pipeline | Message routing and filtering rules |
| Standby failover of the listener | Firewall approvals for the inbound port |
Reliability guarantees
The platform delivers no message loss on session interruption, provided:
- The adapter is deployed in Single Writer mode with at least two replicas.
- The counterparty's protocol supports sequence numbers and gap recovery.
- The internal destination (such as a broker) is healthy enough to accept messages.
If any of those conditions do not hold, the adapter falls back to session-level recovery (resend requests, reconnect loops) and surfaces the degraded state through the Portal.
See also
- Protocol Bridging for connecting two systems that speak different protocols.
- Multi-Venue Aggregation for consolidating feeds from many counterparties.