---
title: "Kafka share.acquire.mode: batch_optimized vs record_limit"
description: "With max.poll.records=3 and producer batches of two, record_limit spans a batch boundary; batch_optimized stops at it and needs one more Kafka poll to drain."
url: https://monedula.dev/kafka-simulator/scenarios/share-batch-optimized/
---

# Kafka share.acquire.mode: batch_optimized vs record_limit

Scenario 11.0.7 · Share group: batch_optimized acquire. Share groups · Advanced · about 3 min · Apache Kafka 4.3.

share.acquire.mode=batch_optimized stops a poll at a producer-batch boundary instead of spanning two batches (KIP-932).

Run it: https://monedula.dev/kafka-simulator/playground/?scenario=11.0.7

## What you start with

A share consumer's acquire mode decides how a single poll carves records out of the log. With records written in producer batches of two, two single-member groups poll the same partition with the same max.poll.records=3: record_limit (the default) grabs three contiguous records even across a batch boundary, while batch_optimized stops at the next producer-batch edge so one acquisition never spans two batches.

## Step by step

1. **Cluster ready · idle** (t+0.000s): One partition, two share groups on it: 'rl' (record_limit) and 'bo' (batch_optimized), both with max.poll.records=3 and batchSize=2. Press ▶. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=11.0.7&t=0)
2. **Producer wrote 3 batches of 2** (t+0.580s): p1 flushed three fixed-size batches - offsets {0,1} {2,3} {4,5} - all replicated (HW=6) before either group's first poll. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=11.0.7&t=1)
3. **Poll 1 · boundary stop vs span** (t+0.660s): Both groups poll with max.poll.records=3. record_limit ('rl') grabbed offsets 0,1,2 - spanning batch {0,1} into {2,3}. batch_optimized ('bo') stopped at the batch-0 boundary and grabbed only 0,1; its 3rd slot went unused. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=11.0.7&t=2)
4. **Poll 2 · bo trails by a batch** (t+1.260s): 'rl' accepted 0,1,2 and acquired 3,4,5 - fully drained next poll. 'bo' accepted 0,1 and acquired the next whole batch 2,3, again stopping at the boundary - still two records behind. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=11.0.7&t=3)
5. **Poll 3 · rl done, bo finishing** (t+1.860s): 'rl' has accepted all six. 'bo' accepted 2,3 and acquired its last batch 4,5 - it needed an extra poll because each acquisition stops at a producer-batch boundary. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=11.0.7&t=4)
6. **Both groups drained** (t+2.460s): 'bo' accepted 4,5 - all six records acked in both groups. batch_optimized never split a producer batch across two polls; the price was one more poll to drain the same backlog. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=11.0.7&t=5)

## The takeaway

batch_optimized aligns acquisitions to producer-batch boundaries - cheaper for the broker to track, at the cost of sometimes acquiring fewer records per poll than the record limit allows.

## Configs in this scenario

- [`share.acquire.mode`](https://kafka.apache.org/43/configuration/consumer-configs/#consumerconfigs_share.acquire.mode): How a share-group member batches the records it acquires in one poll: record_limit grabs up to max.poll.records of the lowest available offsets, while batch_optimized additionally stops at the next producer-batch boundary so a single acquisition never spans two producer batches - fewer, batch-aligned acquisitions at the cost of sometimes-smaller polls.
- [`max.poll.records`](https://kafka.apache.org/43/configuration/consumer-configs/#consumerconfigs_max.poll.records): The most records one poll() returns (default 500); a smaller value shortens the processing between two polls, which keeps a group member inside max.poll.interval.ms.

## Further reading

- [KIP-932 on the Apache Kafka wiki](https://cwiki.apache.org/confluence/display/KAFKA/KIP-932%3A+Queues+for+Kafka)