When is a single-partition topic justified for ordering, and what alternatives give ordering without sacrificing throughput?

## Why single partition = global order Kafka orders only within a partition. So the *only* way to totally order an entire topic is to have exactly **one partition**: all records funnel into one append-only log with one offset sequence. ## The cost - **No parallelism in the consumer group:** at most one consumer instance can own a partition, so consumption can't scale out. Throughput is capped at a single consumer's rate. - **Broker hotspot:** one broker is the leader for that partition and handles all produce/replicate/fetch traffic for the topic. You can't spread load. - **No room to grow:** you can add partitions later, but that *breaks* the global-order property you bought the single partition for, and remaps any keys. ## When it's actually justified Reserve single-partition topics for **low-volume streams where global order is a genuine requirement**: a cluster-wide config/feature-flag change log, a small audit/command stream, a leader-election or sequencing channel. The volume is low enough that one consumer keeps up, and the semantics demand a single global timeline. ## The better default: keyed multi-partition For almost everything, you don't need *global* order — you need **per-entity order** (all events for one user/order/account ordered). Use a multi-partition topic keyed by that entity: - Same key -> same partition -> per-key total order. - Different keys spread across partitions -> parallel consumption. This gives ordering *where it matters* and scaling *everywhere else*. ## Design decisions for the keyed approach 1. **Pick the key = your ordering domain.** If you need orders ordered per customer, key by customerId. The key defines the granularity of both ordering and parallelism. 2. **Size partitions generously up front.** Because partition selection is `hash(key) % numPartitions`, increasing partitions later remaps keys and breaks cross-boundary per-key order. Over-provisioning partitions is cheaper than repartitioning an ordered topic. 3. **Watch key hotspots.** A skewed key (one giant customer) bounds that key's throughput to one partition. Mitigate by sub-sharding the key (e.g. `customerId#bucket`) when global per-customer order can be relaxed to per-bucket order, or accept the cap. 4. **Consumer parallelism = partition count.** You can't have more *active* consumers in a group than partitions, so partition count also caps consumer scale-out. ## Principal-level framing Global total order is an expensive, rarely-true requirement. The architectural job is to *narrow* the ordering requirement to the smallest domain that the business actually needs (usually per-entity), express that as the partition key, and size partitions for both throughput and future growth — so you never have to choose between order and scale.