@RunLLM I'm using key_shared policy, same subscription name, two consumers, a single partition for the topic, and when i use org_id as partition key and device_id as ordering key, I'm seeing no overlap in org_id in the consumers however, when I use device_id as partition key and org_id as ordering key, I am seeing overlap in org_id in the consumers i thought ordering key is used to route messages to the consumer?

In Pulsar's Key_Shared subscription, the message key (partition key) or ordering key is used to determine which consumer receives a message. If an ordering key is set, it takes precedence for routing; otherwise, the partition key is used. This means messages with the same ordering key will always be delivered to the same consumer, preserving order for that key. If you use device_id as the ordering key, all messages with the same device_id go to the same consumer, regardless of org_id. If you use org_id as the ordering key, all messages with the same org_id go to the same consumer, regardless of device_id. Overlap occurs if the ordering key does not uniquely identify the grouping you expect. According to Pulsar documentation and TypedMessageBuilder.java, ordering key is used for dispatch in Key_Shared mode, and partition key is only used if ordering key is not specified. Would you like more detail on how the routing logic works internally? Sources: - Pulsar documentation: Key_Shared - TypedMessageBuilder.java 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@RunLLM does keeping ordering key empty mean we're not setting it?

Yes, if you do not set the ordering key (i.e., leave it empty or unset), Pulsar will ignore it and use the partition key (message key) for routing in Key_Shared subscriptions. The ordering key only affects routing if it is explicitly set; otherwise, the partition key is used as the fallback according to TypedMessageBuilder.java. Would you like more detail on how Pulsar distinguishes between unset and empty ordering keys? Sources: - TypedMessageBuilder.java 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@RunLLM is there another point for the ordering key?

The primary purpose of the ordering key in Pulsar is to control message dispatch in Key_Shared subscriptions, ensuring all messages with the same ordering key are delivered to the same consumer and in order. If the ordering key is not set, the partition key is used instead for this purpose. There is no other documented use for the ordering key outside of message routing and ordering in Key_Shared mode, as described in TypedMessageBuilder.java. Would you like more detail on scenarios where ordering key is preferred over partition key? Sources: - TypedMessageBuilder.java 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

> is there another point for the ordering key? @KP good question. I've been wondering about this same detail. I guess having separate partition key and ordering key is only useful in producing to multi-topic partitions. The partition key will determine would partition the message will be sent to. It allows having a higher level grouping so that all messages in that group get sent to the same partition. When the ordering key is separate, it allows processing the messages in the partition using Key_Shared subscriptions in lower level key order.