Kafka consumer group rebalance simulator
Add and remove consumers and watch partitions move. Compare range, round-robin, sticky and cooperative assignment, and see what a rebalance does to lag, committed offsets and ordering.
Top: consumers (click one to make it leave). Bottom: partitions of the topic. Dashed outline = records in the log, light fill = read so far, solid fill = committed.
Event log
How Kafka decides who reads what
Every consumer in a group shares one group id. Kafka guarantees that each partition is read by exactly one consumer of the group at a time, which is how a topic with six partitions can be processed by up to six workers in parallel. A rebalance is the moment the group re-agrees on that split. It is triggered by a consumer joining, leaving or crashing, or by partitions being added.
The four strategies you can try above
- Range sorts consumers by member id and gives each a contiguous block per topic, so the first few consumers get one extra partition when the numbers do not divide evenly. With several topics this can leave the first consumer with more total work.
- Round-robin lists every partition of every subscribed topic and deals them out one at a time, which is more even across topics.
- Sticky aims for a balanced assignment but, unlike the first two, tries to keep each partition with its previous owner, so a joining consumer takes only what it needs.
- Cooperative sticky reaches the same result as sticky in two rounds. In round one only partitions that must move are revoked; everything else keeps being consumed. This removes the stop-the-world pause of the eager protocol.
What the colours and numbers mean
The dashed outline of a partition is its log end offset. The light fill is how far its current owner has read, and the solid fill is the committed offset. Lag is end minus committed, which is what monitoring tools report. When a partition changes owner, the new owner starts at the committed offset, so records between committed and read are processed again. That is why commit timing decides how many duplicates you see, and why handlers should be idempotent.
Ordering during a rebalance
Kafka orders records only within a partition. Because a partition always has one reader, and the new reader continues from the committed offset, order inside the partition is kept. If you need strict per-key ordering, use the same key for related records, commit in the revoke callback, and avoid handing work to background threads that outlive the partition assignment.
Learn the concepts
Kafka rebalancing ·Consumer groups ·Offsets and commits ·Kafka consumer ·Spring Kafka listeners ·Kafka partition calculator
This is a teaching model. Range and round-robin follow the Apache Kafka algorithms exactly; the sticky assignors follow the constrained algorithm used when every member subscribes to the same topics.
Frequently asked questions
What is a Kafka consumer group rebalance?
A rebalance is the process where the group coordinator and the consumers agree on which consumer reads which partition. It runs whenever a consumer joins or leaves, a consumer is considered dead after missing heartbeats or exceeding max.poll.interval.ms, or the topic gains partitions.
What is the difference between range, round-robin, sticky and cooperative sticky?
Range gives each consumer a contiguous block of partitions per topic. Round-robin deals partitions out one by one across all topics. Sticky produces a balanced assignment while moving as few partitions as possible. Cooperative sticky produces the same assignment as sticky but performs the move in two rounds, so consumers keep reading the partitions they keep.
Why do I see duplicate records after a rebalance?
A consumer that loses a partition does not tell the new owner how far it got. The new owner starts at the last committed offset, so everything read but not yet committed is processed again. Kafka offers at-least-once delivery by default, so handlers should be idempotent.
Does a rebalance break message ordering?
Order is guaranteed inside one partition. After a rebalance the new owner resumes that partition in order from the committed offset. Ordering across partitions was never guaranteed. The risk is overlap: if the old owner is still processing while the new one starts, the same key can be handled twice at the same time.
Is this simulator the real Kafka client?
No. It is a small model. The range and round-robin assignments match the Apache Kafka algorithms, and the sticky assignment follows the constrained algorithm used when all members subscribe to the same topics. Timing, heartbeats and the group coordinator are simplified.