How do you scale ActiveMQ horizontally?

ActiveMQ Classic doesn't scale like Kafka's partitioned log - a single Queue lives on a single broker - so horizontal scale is achieved through composition rather than built-in partitioning:

1. Network of brokers - spread different destinations or consumer groups across multiple connected broker instances so no single broker handles all traffic.
2. Client-side sharding - deliberately split traffic across several independent queues/brokers by a partition key, such as customer ID, where producers and consumers know which broker owns which shard.
3. Virtual Topics / composite destinations - fan messages out to multiple consumer groups that can then each scale their own worker pool independently.
4. Migrate hot destinations to dedicated broker instances so one noisy destination doesn't starve others sharing the same broker's resources.

None of these give Kafka-style automatic partition rebalancing - the sharding and routing logic has to be designed into the application or topology up front. If genuinely elastic, automatically rebalanced horizontal scaling is the primary requirement, that's usually a signal to evaluate Kafka or ActiveMQ Artemis clustering rather than to force it onto ActiveMQ Classic.

A practical illustration: an order-processing system might shard by region, running a separate broker, or queue, per region so that a spike in one region's traffic doesn't starve consumers processing another region's orders. Consumers for each shard only ever connect to their own broker or queue, and a new region can be added by standing up a new shard rather than reconfiguring the whole fleet. This kind of design has to be planned deliberately, though - unlike Kafka, ActiveMQ won't automatically redistribute partitions if one shard becomes hotter than the others; an operator has to notice the imbalance and manually rebalance which keys route to which shard.