메시지 키와 파티셔닝 전략

Every Kafka record can carry an optional key. The key is not just data — it determines which partition the record is written to.

When a key is present, the default partitioner hashes it and maps the hash to a partition. The same key always lands in the same partition (for a fixed partition count).

If you send records without a key, the producer distributes them across partitions (sticky batching in modern clients) for balanced load — but ordering across partitions is not guaranteed.

Kafka guarantees ordering only within a partition. By keying related records (e.g. all events for one order id), you guarantee they are processed in order.

A good key reflects your ordering and grouping needs.

• User events keyed by userId.
• Order events keyed by orderId.
• Avoid keys with too few distinct values (causes hot partitions).

If one key value dominates traffic, its partition becomes a hotspot while others sit idle. Watch key cardinality and distribution to keep load balanced.

Pass the key as the second argument to send; Spring forwards it to the partitioner.

For special routing logic, implement the Partitioner interface and override partition().

Tell the producer to use your class via configuration.

Changing the partition count changes hash % numPartitions, so existing keys may move to new partitions, breaking ordering. Choose partition count carefully up front.

Keys are the link between data and partitions. They give you per-key ordering, drive load distribution, and can be customized with a partitioner for advanced routing.

You learned message keys and partitioning.

• The key determines the target partition via hashing.
• Same key, same partition, ordered processing.
• Low-cardinality keys cause hot partitions.
• A custom Partitioner enables advanced routing.