Fix Kafka wrong partition key
Free Kafka lab: events ship before payment because a random UUID key breaks per-order order. Key by orderId — no sign-up.
Shipping events fire before payment is confirmed. Kafka only preserves order inside a partition. A random UUID key spreads one order’s events across partitions, so consumers see them interleaved.
OrderEventPublisher calls kafkaTemplate.send(topic, UUID.randomUUID().toString(), event). Hash of a random key lands related events on different partitions. Consumers that scale beyond one instance then process payment and shipping out of sequence.
The lab fix is to key by orderId so every event for that order stays on one partition. Throughput still comes from more partitions and more keys — not from random keys. This is the standard ordering question in backend interviews.
What you will cover
- Symptom: shipping before payment for the same order
- Order is guaranteed only within a partition
- Root cause: ProducerRecord key is a random UUID
- Wrong fix: a single-thread consumer on all partitions
- Right fix: key by orderId (the business id)
Related free labs and modules
- RestTemplate without timeout
- Distributed systems module
- HikariCP pool exhaustion
- All free debug labs
Common questions
Why are Kafka events out of order across partitions?
Kafka orders records only inside a partition. If the producer key is random, events for one order hash to different partitions and consumers can process them in any interleaving. Key by a stable business id such as orderId.
Should I use a random Kafka partition key for load balancing?
Random keys spread load but destroy per-entity order. Use the entity id when sequence matters (orders, payments, account updates). Use more partitions and more distinct ids when you need throughput.
Is the Kafka partition-key lab free?
Yes. The wrong-partition-key lab is lifetime-free in the browser. No account required.
Free Spring Boot debug challenges · Free debug challenges · Java Spring Boot path · Create free account