Bounded Kafka consumer range skips or duplicates records after rebalance

Goal

Consume a fixed offset range using seek() and stop at a target end offset, effectively paginating a large dataset without server‑side query pagination.

Constraints and uncertainty

Consumer group rebalances revoke partitions; the committed offset determines the resume point. If the application commits before the range is fully processed, records may be skipped; if it commits after, duplicates appear. The poll() batch limits (max.poll.records, max.poll.interval.ms) require manual tracking of processed offsets to implement pagination within the bounded range. Tiered storage retains offset semantics but may increase fetch latency for historical segments.

• What commit strategy guarantees no gaps or duplicates when seeking a bounded offset range?
• How does the consumer's position() interact with a manual pagination cursor during a rebalance?
• Does enabling exactly‑once semantics remove the need for explicit offset tracking in this scenario?