How can you optimize consumer throughput with Key_Shared subscriptions?

Ensure message keys have enough distinct values and reasonably even distribution across them - if most messages share one or a few keys, that traffic still funnels to a single consumer each, capping parallelism regardless of how many consumer instances are added.

Scale the number of consumer instances to roughly match, or stay below, the practical number of distinct, active keys at any given time, since adding more consumers than there are actively-flowing keys just leaves extra consumers idle rather than increasing throughput.

Tune receiver queue size and permits per consumer appropriately - too small a queue can throttle a fast consumer waiting on network round-trips for more messages, while an oversized queue on a slow consumer can cause it to hold an unfair share of in-flight, unacknowledged key ranges.

Watch for consumer churn: every time a consumer joins or leaves a Key_Shared subscription, key-range ownership is recomputed, briefly pausing processing for the reassigned ranges - so a subscription with frequent connect/disconnect cycles, from crash-looping or aggressive autoscaling, sees lower effective throughput than the same consumer count running stably.