Kafka only guarantees message ordering within a single partition, so that guarantee can be broken any time related messages end up spread across multiple partitions or when the partition-to-key mapping changes.
Key Points: • If a producer doesn't use a consistent key, records can be spread across partitions via round-robin, and order across those partitions is not guaranteed. • Increasing a topic's partition count changes the hash-to-partition mapping, so messages with the same key sent before and after the change can land on different partitions. • Producer retries without idempotence enabled can cause records to be reordered within a partition if an earlier batch fails and a later one succeeds first. • Rebalancing a consumer group doesn't reorder data within a partition, but a consumer processing partitions out of lockstep can still process events for different keys out of "wall clock" order relative to each other, even though per-partition order is preserved.
Example: An application relying on order events being processed strictly in sequence would break that guarantee the moment it adds partitions to the "orders" topic, since order events for a given order ID could suddenly start hashing to a different partition than earlier events for the same ID.
Interview Tip: A concise interview answer is:
"Kafka only guarantees order within a partition, not across the whole topic, so that guarantee breaks if messages for the same logical entity aren't consistently keyed to the same partition, if the partition count changes after messages have already been produced, or if retries happen without idempotent producer settings enabled."