Pattern · seen in 1 breakdown across 1 company

Batched Routing by Destination

Definition

Batched routing by destination is a strategy for issuing bulk operations against partitioned downstream systems without paying the fanout cost of cross-partition batches. Incoming items arrive in an interleaved stream (orders by region, log lines by service, messages by tenant); a routing layer groups items by their downstream destination (database shard, search cluster, partition, node) and issues each bulk operation against a single destination. The result: each bulk operation has a narrow fault domain, single-destination failures no longer cause widespread batch failures, and the downstream system can apply per-destination optimizations.

The failure mode the pattern addresses is fanout amplification of single-point failures. When a bulk operation contains items destined for many backend nodes — say, 50 messages going to 50 different shards — the operation as a whole is considered failed if any single destination fails. A single failed node causes a disproportionate fraction of bulk operations to fail. With 100 evenly-distributed destinations and 50-item batches, a single-node failure causes roughly 40% of bulk operations to fail (the math is approximately 1 - (99/100)^50). The failure mode scales badly: more destinations make it worse, not better.

The fix is to require each bulk operation to target exactly one destination. The routing layer reads the stream, examines each item's destination key, and dispatches the item to a per-destination collector. Each collector accumulates items until it has enough to issue a useful bulk operation (or until a timeout fires), then sends the batch to that destination only. Single-destination failures now affect only their own batches; multi-destination failures still exist but are bounded by the destinations affected, not by the cross-product of destinations in any batch.

The implementation pattern is straightforward in any language with first-class concurrency primitives: a dispatcher reads the stream, a per-key task pool collects items into batches, and timeouts force batches to flush even when not full. Discord's 2025 implementation uses Rust tokio tasks with one task per cluster+index destination. The same shape appears in many systems: Kafka producers batching by partition, database connection pooling with per-shard batches, log aggregators batching by destination index.

When it applies

01Indexing pipelines feeding sharded or partitioned search systems where bulk operations are the throughput-optimal write path but cross-shard batches amplify failure rates

02Database write pipelines targeting horizontally-partitioned data stores (sharded Postgres, Cassandra by partition key, DynamoDB by partition) where cross-partition writes have higher overhead than single-partition writes

03Log and metric aggregation systems shipping data to multiple downstream destinations where keeping batches destination-specific improves both throughput and isolation

04Any bulk-operation API where the operation's failure semantics are 'all-or-nothing per call' and the cost of a partial-batch failure is high (re-enqueueing, retrying, or surfacing errors to users)

05Pipelines transitioning from naive batching to fault-tolerant batching as scale grows past the point where cross-destination failure amplification becomes operationally visible

Tradeoffs

Batched routing adds end-to-end latency. Items wait in their per-destination collector until the batch fills or the timeout fires. For workloads that need 'searchable within seconds,' this is fine; for workloads where every millisecond of indexing latency matters, the latency added by batching may be the wrong tradeoff.

Per-destination state accumulates in the routing layer. With N destinations, the routing layer holds N collectors, each with their own buffer of pending items. Memory cost is real, especially when destinations are numerous and items are large. Discord's 2025 architecture has thousands of destinations (clusters times indices), each potentially holding a batch in flight.

Destinations with low traffic spend most of their time waiting for timeouts. A destination that receives 1 item per second with a batch size of 100 and a timeout of 1 second sends 1-item batches most of the time, which defeats the throughput benefit of batching. The pattern works best when traffic distribution is reasonably balanced across destinations or when timeouts are tuned per-destination.

The routing layer becomes a critical, stateful, in-line component. If the router dies, in-flight items in collectors are lost (unless the collectors themselves are persistent). Production implementations usually pair this with a durable upstream queue so that router failures can be recovered by replay rather than by data loss.

Adding new destinations is a dynamic operation. The router must handle destination discovery, collector creation, and destination retirement gracefully. Static-destination implementations are simpler; dynamic ones are more flexible but require more careful design.

The same move, 1 ways

Every row is a production system that bet on this pattern — the note says how, in that system's own terms.

Discord

Discord Engineering

2025

The Rust routing layer reads PubSub messages, groups them by destination (a cluster-and-index pair), and sends each batch to a single node. This replaced the old model, where one batch could fan out across many nodes and a single failed node would sink an outsized share of operations. The general pattern: keep the throughput win of batching while keeping each batch's blast radius small. Read the breakdown →

Problems this pattern answers

The walls where its breakdowns live — each opens the cross-company comparison.

Blast radius scales with cluster sizeDISCORD →