Committed Offsets and auto.offset.reset

Where each VaultCommerce consumer group resumes after restart — committed offsets and reset policies.

Intermediate10 min read

Read these first

Consumer Groups and Partition Assignment

Why this matters

VaultCommerce disables auto-commit — offsets commit only after inventory reservation succeeds in Postgres.
auto.offset.reset=earliest on new groups replays history; latest skips backlog.
Wrong commit timing is the #1 cause of duplicate or missed processing.
Offset tools are essential for incident recovery and reprocessing.

Poll records

Business logic

Offset +1

Process batch → commit offset. On restart, consumer resumes from last committed position.

Commit strategies

Sync commit after each record: safe, slow. Batch commit every N records: faster, riskier on crash. VaultCommerce commits per record on payment topics, every 100 on analytics. commitSync() blocks until broker acks offset.

Key points

Committed offset — next record to read on restart
auto.offset.reset — behavior when no committed offset exists (earliest/latest/none)
enable.auto.commit — periodic background commit (default true; VaultCommerce sets false)
__consumer_offsets — internal compacted topic storing commits
seek() — programmatic offset jump for testing or recovery

Reset and replay

kafka-consumer-groups.sh --reset-offsets moves bookmarks for reprocessing. VaultCommerce used --to-datetime after a bad deploy to replay 20 minutes of orders through fixed code. Requires consumer group stopped.

VaultCommerce rollout checklist

Before promoting changes that touch inventory-service and payment-service consumer groups, run the staging KRaft cluster (Kafka 3.7+, Schema Registry 7.x) through a 10k events/min soak test. Compare producer request latency p99 and consumer lag per group against the pre-deploy baseline. Commit after side effects are durable. Document the change in the internal topic registry, attach Grafana screenshots to the change ticket, and keep an engineer on lag dashboards for 30 minutes after production rollout — roll back the service release before altering broker-level settings if lag or under-replicated partitions spike.

Java

# VaultCommerce incident — replay orders after bad deploy (group stopped first)
kafka-consumer-groups.sh --bootstrap-server kafka-1:9092 \
  --group inventory-service \
  --topic vaultcommerce.orders.placed.v1 \
  --reset-offsets --to-datetime 2026-09-15T14:00:00.000 \
  --execute

kafka-consumer-groups.sh --bootstrap-server kafka-1:9092 \
  --describe --group inventory-service

Quick recall

Everything you need if you only revisit this box.

Commit after side effects are durable.
Disable auto-commit for critical consumers.
Reset offsets only with group stopped.

Test yourself

Answer these before moving on — recall is what makes it stick.