Transit events for an entire metro region are spread across many Kafka partitions for throughput. What ordering guarantee should planners expect?
Select an answer to reveal the explanation.
Short Explanation
Think of many checkout lanes—each lane stays in order, but the mall does not promise one giant single-file line. Kafka keeps order per partition, not automatically across every city event. If you need a wider sequence, you design keys and consumers for it.
Full Explanation
Kafka-style partitioning raises throughput for metro-scale transit topics, but ordering is preserved within each partition that is keyed consistently—not as a free citywide total order across every event. Planners should expect per-partition sequence guarantees and treat global ordering as an application design choice involving key strategy, partition count, and consumer merge logic. That awareness prevents false assumptions when regional agencies publish into a highly partitioned bus.
Brokers do not silently sort every city event into one absolute timeline before delivery; doing so would serialize the entire metro feed and defeat the throughput goal of partitioning. Consumers likewise do not automatically merge partitions into a single citywide sequence without deliberate design such as watermarking, sequence numbers, or constrained keys. Claiming that partitioning removes ordering concerns because messages arrive in wall-clock time confuses network arrival with logical order and ignores clock skew across producers.
Exam caveat: if a use case truly needs stronger ordering, architects may reduce key cardinality, colocate related entities on one partition, or apply application-level sequencing—each choice trades throughput or complexity. Operational check: publish a sequenced pair of related vehicle events with the same partition key and a second pair with different keys, then verify only the same-key pair retains relative order at the consumer.