Multi-Venue Aggregation
Use this pattern when your firm connects to several counterparties (exchanges, ECNs, liquidity providers, prime brokers) and needs a single normalized feed for downstream consumption. Each counterparty has its own protocol dialect, session rules, and message formats; the platform hides those differences behind a consistent output contract.
Each venue gets its own adapter. Onboarding a new venue means creating a new adapter configuration, not a new integration project.
Conceptual flow
All adapters publish to the same destination in the same normalized format. Consumers read from a single location and do not need to know how many venues are feeding it or which dialect each venue speaks.
Per-venue isolation
| Property | Behavior |
|---|---|
| Session lifecycle | Each venue's session is owned by one adapter. A session problem at one venue does not stop the others. |
| Transformation pipeline | Each adapter has its own pipeline. Venue-specific quirks (tag renames, field mappings, custom enumerations) stay local to that adapter. |
| Redundancy | Each adapter can be deployed in Single Writer mode with its own standby independently. |
| Observability | Each venue is its own adapter, so its status and event log are tracked separately in the Portal; throughput and latency are available per venue through the platform metrics. |
Normalization strategies
| Approach | When it applies |
|---|---|
| One normalized schema across all venues | All venues produce equivalent business events; differences are purely syntactic. Implement full normalization with a custom transformer built on the Plugin SDK. |
| Venue-tagged normalized records | Downstream consumers need to know which venue produced each record (for routing, P&L attribution, or reconciliation). Attach a venue identifier as a header with header-enricher-transformer, or carry it as an envelope field with json-envelope-transformer. |
| Partial normalization | Some fields are normalized, others are preserved verbatim for specialist consumers. Use json-envelope-transformer to carry both forms. |
When to use
| Scenario | Pattern |
|---|---|
| Downstream teams consume a single topic instead of one per venue. | Aggregate into a single normalized destination. |
| Venue onboarding time is a bottleneck. | Standardize the adapter template and reuse it for each new venue. |
| You need per-venue attribution downstream. | Include a venue identifier header during transformation with header-enricher-transformer. |
See also
- Venue Connectivity for the single-venue building block that this pattern composes.
- Protocol Bridging for enriching the normalized output with routing metadata.