Use a stable key for the smallest entity whose events must stay in order when you need per-entity ordering and parallel processing. Use a single-partition topic only when every record needs one topic-wide sequence and you can accept that each consumer group processes that topic through one consumer at a time.
How Kafka message ordering works
Kafka stores a topic as one or more partitions. Each partition is an ordered log: consumers read its records in the order they were written. Kafka routes records with the same event key to the same partition under its documented keyed-partitioning behavior, which lets an application keep a sequence together. Apache Kafka documentation: Introduction
The ordering boundary is the partition, not the topic as a whole. Kafka’s 4.1 design documentation states that records have a total order within a partition, but not between different partitions in the same topic. Apache Kafka 4.1: Design
Should you use a key or one partition?
| Choice | Ordering scope | Consumer-group parallelism | Best fit |
|---|---|---|---|
| Stable entity or session key with multiple partitions | Records sharing a key are routed to the same partition, so their order can be preserved within that partition. There is no total order across different partitions. | Consumers in the group can process separate partitions in parallel, subject to partition assignment. | Independent customers, accounts, devices, or sessions whose events each need their own sequence. |
| One partition for the topic | One total order across all records in the topic. | One consumer process per group can consume that topic’s sole partition at a time. | Workflows in which every record must be ordered against every other record. |
The one-partition trade-off is part of Kafka’s design: a single-partition topic can provide a topic-wide total order, but each consumer group can use only one consumer process for that sole partition at a time. Apache Kafka 4.1: Design
Free tools Windows power users keep installed
One-click scans. No signup required.
#1 Best Overall
How to choose the right key
Choose the key based on the ordering invariant in your application: which records must be handled in sequence, and which can proceed independently? A “session key” is not a special Kafka feature or guarantee; it is an application’s choice of key. Keep it unchanged for all events that belong to the same ordered sequence.
- Use a session identifier when each session has its own independent sequence and ordering need not continue between sessions.
- Use a stable entity identifier—such as a customer, account, or device ID—when events must remain ordered across multiple sessions for that entity.
- Do not assume the key creates one global order. It groups records onto a partition; records on other partitions have no defined relative order.
This follows from Kafka’s same-key routing behavior and the protocol’s description of keys and partitioning. Apache Kafka documentation: Introduction Apache Kafka 2.5: Protocol
What to verify before relying on keyed ordering
- Confirm the producer’s key. Every record that must share an ordered sequence needs the same key value, and the producer must send it as the record key.
- Check the deployed client and partitioner. Kafka 3.8 producer documentation describes keyed records being assigned based on a hash of the key, unkeyed records using a sticky partition, and the availability of round-robin and custom partitioners. Defaults and behavior can vary with client version and configuration, so inspect the producer actually deployed. Apache Kafka 3.8: Producer Configs
- Evaluate key skew. A very active key stays on one partition, which can concentrate processing on that partition. Kafka’s documentation explains key routing and partition-based parallelism but does not set a universal throughput threshold; measure the workload you intend to run.
- Match partitioning to the invariant. More partitions can allow more consumers in a group to work concurrently, but they do not create a topic-wide order. If every record must be sequenced against every other record, use one partition and account for its consumer limit.
Does exactly-once processing change the ordering boundary?
No. Kafka’s transactional and delivery-semantics features address atomic handling of produced records and consumed offsets. They do not turn independently ordered partitions into one globally ordered sequence. Treat delivery guarantees and ordering scope as separate design decisions. Apache Kafka 4.1: Design
Quick Recap
Best Value
Rank #4
- Metamorphosis: Franz Kafka (Little Clothbound Classics)
Rank #3
A practical decision rule
- If each entity or session has an independent sequence, use a stable key for that sequence and enough partitions to support the parallelism your workload needs.
- If any record may need to be ordered before or after every other record in the topic, use one partition and accept one active consumer per group for that partition.
- If the answer depends on throughput, do not infer a winner from partition count alone. Benchmark with representative key distribution, event sizes, producer and consumer settings, client version, and processing cost.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →
