Queues & Background Processing in Depth · Scaling Consumers
Partitioning and Hot Keys
Choose partition keys and handle skew.
Partition keys decide ordering scope and load distribution. A good key has high cardinality and even traffic (order ID, user ID). Hot keys (one huge tenant, a viral product) overload one partition and its consumer. Mitigations: salting keys (tenant#bucketN) when strict per-key order isn't needed, dedicated topics/queues for very large tenants, or splitting work by sub-entity. Plan partition counts ahead — increasing them later remaps keys.
Partition key trade-offs
| Key choice | Ordering | Distribution |
|---|---|---|
| Tenant ID | Per tenant | Skewed (big tenants) |
| Order / entity ID | Per entity | Even |
| Random / round-robin | None | Perfect |
| Salted key (tenant#0..9) | Per salted bucket | Better for big tenants |
# Salting a hot tenant when per-tenant ordering isn't required
key = f"{tenant_id}#{hash(order_id) % 8}" # spreads one tenant over 8 partitions
Common pitfalls
- Keying by a low-cardinality field (country, status).
- Increasing partitions and silently breaking per-key order.
- One consumer pinned at 100% while others idle.
Key points
- High-cardinality, even keys
- Detect and mitigate hot keys
- Size partitions up front
Further reading: Confluent: Choosing partition counts
Practice questions
Why is 'country' a bad partition key?
Answer
Low cardinality and skewed traffic: a few countries dominate, creating hot partitions and limiting parallelism.
What does adding partitions to an existing Kafka topic do to key ordering?
Answer
Keys hash to different partitions after the change, so events for a key may be split across old and new partitions and processed out of order.
Open in the app to mark lessons complete, take notes and track your progress.