A customer balance becomes wrong if its updates are applied out of sequence. In Kafka, message order is guaranteed within a partition, not across partitions or an entire topic. Ordering is therefore an architectural requirement to identify before choosing how events are distributed. section 2.2.3 section 10.1.3
Give related messages a stable key so the producer routes them to the same partition. An account identifier keeps balance updates together; a customer identifier does the same for address or profile changes. A key selects a partition—it does not make messages unique. Within a consumer group, each partition is assigned to one consumer instance, keeping its related updates with that instance. section 2.4.1 section 2.2.3
Figure 2.11 Selecting the key for the Balances topic. The account number is used as the key, ensuring that messages for the same account are routed to the same partition. This setup guarantees that updates for each account are received in the correct order.
The account-number key illustrates the design boundary: balance updates for one account share a partition and retain their order. section 2.4.1
Ordering has costs and limits:
- Separate partitions can be processed independently; do not assume a sequence across them. Without a stable key, default sticky partitioning groups batches rather than related messages. Round-robin distribution can favor balance when ordering is unnecessary. section 3.2.1 section 3.2.6
- Choose the partition count carefully. Increasing it can send later messages for a key to a different partition; one cautious change process stops producers, drains existing data, then restarts them after the increase. section 2.4.6
- Parallel work inside a consumer needs its own discipline. A worker pool sharded by key can preserve per-key order, but offset commits must wait for the highest contiguous completed offset. section 4.3.1
Customer profiles versus transactions
Customer profile updates use customer ID as their key because each customer's changes must be processed in sequence. Transactions do not require that ordering; their transaction IDs instead help distribute load. Record such key decisions in the Kafka message bindings of an AsyncAPI channel so the intended behavior is visible to other teams. section 2.4.2
