Pick the key every read has

Before you start

• Partitioning

  Keys are spread over nodes by hashing. That lesson covers the ring.

  Open lesson

Why it matters

Chat history is always opened for a known conversation, but its messages come from different senders. Splitting by sender scatters Ana’s and Bo’s lines even though readers need them together and in one order. A history request for conversation c1 must be one ordered range read on one partition, without scanning a global message table.

Messages are stored in order per conversation. Readers always know the conversation id. You will not scan a global message table.

Use conversation c1, not sender Ana or Bo, as the partition key, and seq 1, 2, 3 as the ordering key; both 1:1 chat and group g7 then read history from one ordered range.

Store each message under a composite key of (conversation_id, seq). The partitioner uses c1, placing Ana’s c1:1 and c1:3 beside Bo’s c1:2; the sequence orders them within that partition. A group id such as g7 uses the same shape.

To page or reconnect, ask the c1 partition for sequence numbers greater than the client’s last one. That is a contiguous range rather than a merge across senders. The tradeoff is a single very busy conversation: all of its ordered writes still meet at one partition.