A business asks for global ordering across millions of events per day. How would you challenge that requirement?

Per-key ordering: key by the entity whose events must be ordered. This scales with partitions and is the default recommendation.

Version or sequence numbers: producers attach a per-entity sequence, and consumers detect gaps or apply only newer versions. This tolerates reordering without serializing the stream.

Event-time ordering in the consumer: stream processing with windows and watermarks can sort by event time, accepting bounded lateness. Note that this is event-time order, not arrival order.

Single-partition topic: legitimate for a low-volume, high-value stream such as a ledger or configuration changes, where simplicity beats scale. I would add an alert on lag and a runbook for failover, and document the growth limit.

Sequencer or database as the authority: if a strict global sequence is needed for something like invoice numbering, generate it in a transactional store and publish events afterwards, rather than relying on Kafka arrival order.

Important nuance: even a single partition orders records by the order the broker received them, not by when business events happened. With multiple producers, global order equals arrival order, which may not match real-world order.

Common mistake: believing you can get global order across topics or by adding consumers on a multi-partition topic. You cannot. Another is accepting the requirement without asking what breaks if two unrelated events swap.

Version note: idempotent producers (default in clients 3.0+) preserve order within a partition across retries, but check the client version and explicit overrides before relying on that.