Kafka share groups (introduced in KIP-932, production-ready since Kafka v4.2) bring a new cooperative event consumption model to Kafka, enabling queue-like behavior. Historically, Kafka's traditional consumer groups have imposed a concurrency bottleneck because the number of active consumers can’t exceed the number of partitions. Share groups remove this constraint: individual records are handed to any available consumer in the pool under a per-record acquisition lock, which the consumer must explicitly acknowledge. On failure or timeout, the record is released and redelivered to any consumer in the group, up to a configurable maximum number of delivery attempts. This provides at-least-once delivery with the possibility of duplicate-processing. Records that exhaust their delivery attempts are archived; dead-letter queue support (KIP-1191) is not yet available.
The tradeoff is that share groups don’t guarantee per-partition ordering because records are dispatched and redelivered independently. However, for teams that previously had to run both Kafka and an external queue system, share groups can simplify the architecture by consolidating workloads onto Kafka.
