Fan-Out and Drop Copy
Use these patterns when a single inbound feed must reach more than one destination. They differ in intent: content-based fan-out splits a feed by evaluating a condition on each message and routing it to the matching destinations, while drop copy duplicates every message to several destinations unconditionally, typically for regulatory archiving, surveillance, or risk monitoring. Both are properties of the pipeline, not features of the source.
Content-based fan-out
Use content-based fan-out when a single inbound feed needs to be split across multiple destinations based on the contents of each message. The pipeline evaluates a condition against each message (for example, a field in the payload) and directs the message to the matching route.
A single ingestion point can feed any number of routes, each with its own condition, transformations, and destination. It scales from a handful of routes to a high-volume feed distributed to many consumers.
Conceptual flow
Each route is evaluated independently. A message that matches multiple conditions is delivered to every matching route. A route with no condition is unconditional: every message passes through it. This combination is what makes fan-out both precise (filtered routes) and reliable (a catch-all archive can sit alongside the filtered routes).
Condition types available
| Condition | What it evaluates | When to use it |
|---|---|---|
| Payload field match | A value at a specific path inside a structured payload (for example, a JSON field). | Routing based on message content such as order status, instrument type, or asset class. |
| Protocol-level attributes | Attributes exposed by the source protocol (such as message type). | Separating control messages from application messages. |
Each condition type is supplied by a plugin: payload field match is the jsonpath-condition in the Essentials plugin, and protocol message-type matching is provided by a protocol plugin such as the fix-message-condition in the FIX plugin.
Conditions are defensive: if a message cannot be evaluated (for example, the payload is not in the expected format), the condition returns false rather than failing the pipeline. The message is skipped by that route and continues through any other matching routes.
Reliability properties
| Property | Guarantee | Conditions |
|---|---|---|
| Per-route acknowledgment | Each route acknowledges independently. A slow destination does not block the others. | The destination supports independent acknowledgment. |
| No duplicate suppression across routes | A message matching two routes is delivered to both. | This is intentional. Use conditions to partition traffic if you need exclusivity. |
| Defensive condition evaluation | An unparseable payload does not crash the pipeline. | The condition returns false and the message is treated as non-matching for that route. |
Drop copy
Use drop copy when a feed must be captured independently of the primary processing path, typically for regulatory archiving, surveillance, or risk monitoring. The platform delivers the same message to multiple destinations so that the capture copy is byte-identical to the message delivered to the primary destination.
Drop copy differs from fan-out in intent: fan-out splits a feed by content, drop copy multicasts the same payload to several destinations unconditionally.
Conceptual flow
A single pipeline route publishes the message to every listed destination. No conditions are evaluated and no transformations are applied between copies: the same enriched record goes to each destination.
Single-step multicast is a broker-transport capability. The message is fanned out to a list of broker topics in one egress step (for example, the Kafka multi-topic send). Targets that are not broker topics (for example, two separate FIX sessions) cannot share one egress step; deliver to each of those with its own route.
When to use
| Scenario | Pattern |
|---|---|
| Peel off a specific message subtype to a dedicated downstream system. | Content-based fan-out: add a route with a condition that matches that subtype. |
| Keep an archive or capture copy of every message, regardless of filtering. | Add an unconditional route alongside the filtered routes. |
| Split a feed where each message must go to exactly one destination. | Content-based fan-out with mutually exclusive conditions across the routes. |
| Send a byte-identical copy to risk, surveillance, or compliance systems. | Drop copy: multicast the same payload to each destination. |
See also
- Protocol Bridging for translating between protocols through a broker.
- Kafka Patterns for the broker-level multi-topic multicast that drop copy uses.