Load-balanced connections in a NiFi cluster

Start here when the downstream system depends on sequence, such as status updates for one account, ledger entries or change events that must be applied in the order they were produced. Round robin spreads consecutive FlowFiles across nodes, so two records that arrive one after another can be processed and delivered by different nodes at different speeds. Single node keeps the queue on one node and is easier to reason about, but that node becomes the throughput ceiling for the connection.

• Round robin removes ordering: once records hop between nodes, nothing guarantees they reach the destination in arrival order.
• Single node keeps sequence visible: all FlowFiles pass through one node's queue, so prioritizers and expiration behave the way a single-node test shows.
• Concurrent tasks can reorder: a processor with more than one concurrent task can reorder FlowFiles even when the connection preserves order, so review the concurrency setting on each step.
• Retries break order: FlowFiles routed back for a later attempt land behind newer records.

Before production, replay a batch with a deliberately slow destination and a forced node disconnect, then compare the output sequence with the source sequence.

Use partition by attribute when records that share a business key need the same node-local state, such as a cache populated per customer, a session window or a stateful aggregation. The partition attribute must exist on each FlowFile before the connection, and every record with the same value is sent to the same node. Keyed routing does not prevent uneven distribution, so one heavy key can overload a single node while the others sit idle.

• Derive the key from stable data: pick an attribute with values that do not change in transit, such as an account or device identifier, and confirm it is set on every FlowFile.
• Watch key skew: a few heavy keys can dominate one node's queue, so measure the distribution from a representative sample.
• Define a path for missing keys: FlowFiles without the attribute need explicit handling, or they can collapse onto one partition.
• Check state after membership changes: caches and windows held on one node are not automatically rebuilt elsewhere, so confirm how the flow repopulates them.
• Size external lookups per node: each node that holds a key calls the external system, so the load on that system grows with the node count.

Before production, test with a sample that includes the most frequent keys and a record with a missing key, then confirm each key's output arrives from one node.

When each record stands alone, such as independent events, file metadata or API payloads that need no shared state, round robin usually spreads CPU and disk work most evenly across nodes. Each node takes a share of the queue and processes it in parallel, so adding nodes increases capacity without changing the flow. The trade-off is that ordering and per-key locality are given up, so the decision depends on whether the destination accepts unordered writes.

• Even spread across nodes: round robin distributes FlowFiles across connected nodes, which keeps the workload balanced under sustained volume.
• Compression trades CPU for network: compressing data between nodes saves bandwidth on large payloads but adds CPU work at both ends, so test attribute only compression against attribute and content compression with representative payload sizes.
• Per-node backpressure: a slow node fills its own queue, so confirm that connection thresholds suit the expected volume.
• Duplicates after disconnects: a node that drops mid-transfer can cause resends, so the destination must tolerate duplicate records.
• Per-node queue monitoring: uneven queue depth across nodes usually points to a skewed or failing node.

Before production, run a sustained volume test, disconnect one node during it, and confirm the flow resumes and the destination counts match the source.

Some destinations accept only one writer, such as a single output file, a sequential protocol session or an API with a strict concurrency limit. A single node strategy places the connection's queue on one node, which makes that node the writer for everything behind the connection. This fits low to moderate volume where the destination's limit is the real constraint, but it concentrates both load and failure risk on one node.

• Choose the node deliberately: confirm which node will hold the queue and how the flow behaves when that node disconnects or restarts.
• Check the downstream limit first: if the destination can accept the full rate from one node, the strategy costs little; if not, the connection becomes a bottleneck regardless of cluster size.
• Keep the sink step light: heavy transformation after the connection runs only on that node, so move it upstream where possible.
• Coordinate with primary-node sources: sources that run only on the primary node still need a load-balanced connection after them, and the single node target should be set consciously rather than inherited from defaults.
• Plan recovery of queued data: FlowFiles already queued on a lost node must be recovered, so confirm how the cluster reports and restores them.

Before production, measure the sustained throughput the destination accepts and confirm the flow recovers cleanly after the chosen node is removed from the cluster.