---
title: "Kafka share.acknowledgement.mode: implicit vs explicit"
description: "Two Kafka share groups, three records. Implicit mode accepts on the next poll; in explicit mode un-acked offset 2 hits its lock expiry and is redelivered."
url: https://monedula.dev/kafka-simulator/scenarios/implicit-vs-explicit-ack/
---

# Kafka share.acknowledgement.mode: implicit vs explicit

Scenario 11.0.6 · Implicit vs explicit acknowledgement mode. Share groups · Advanced · about 3 min · Apache Kafka 4.3.

IMPLICIT auto-accepts on the next poll; EXPLICIT keeps records in-flight until the member acks - or the lock expires and redelivers (KIP-932).

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

## What you start with

share.acknowledgement.mode controls how records are confirmed. This A/B runs two single-member groups over the same three records: the implicit group auto-accepts each record on its NEXT poll with no application ack, while the explicit group must call share_ack - and the one offset it deliberately leaves un-acked has its lock expire (lockMs 1000) and is redelivered.

## Step by step

1. **Cluster ready · idle** (t+0.000s): One partition, three records pending, and TWO single-member share groups that differ ONLY in ackMode: 'imp' (implicit) vs 'exp' (explicit). Both have a 1000ms lock. Press ▶. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=11.0.6&t=0)
2. **Both groups acquire** (t+0.700s): First poll (600ms): each group's member acquires all three records (deliveryCount 1, locked until 1600ms). Acquiring alone does NOT make a record terminal, so SPSO stays at 0 and both groups read lag 3. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=11.0.6&t=1)
3. **Implicit auto-acked; explicit still in-flight** (t+1.300s): The contrast. IMPLICIT auto-accepted all three on its next poll (1200ms) with no application ack → acked, lag 0. EXPLICIT only acked offsets 0 and 1 (the ones the app called share_ack on); offset 2 is still acquired, so its SPSO is stuck at 2 (lag 1). [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=11.0.6&t=2)
4. **Explicit un-acked lock expires** (t+1.700s): Offset 2 was never acked, so at 1600ms its acquisition lock EXPIRED - the record is released back to 'available' (still deliveryCount 1). Implicit never reached this path; explicit's lock-expiry is the safety net that stops a crashed handler from silently dropping a record. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=11.0.6&t=3)
5. **Explicit record redelivered** (t+1.900s): The next poll (1800ms) re-acquires offset 2 - deliveryCount climbs to 2: a REDELIVERY. Explicit ack buys at-least-once control at the cost of a possible duplicate; the implicit group acked-and-forgot and never duplicated anything. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=11.0.6&t=4)

## The takeaway

Implicit mode is simplest for fire-and-forget processing; explicit mode trades a manual ack for precise at-least-once control, with lock expiry redelivering anything you forget to confirm.

## Configs in this scenario

- [`share.acknowledgement.mode`](https://kafka.apache.org/43/configuration/consumer-configs/#consumerconfigs_share.acknowledgement.mode): How a share-group consumer acknowledges the records it acquires: implicit auto-accepts every acquired record on the next poll (the application just keeps polling), while explicit requires the application to call acknowledge(record, type) per record to ACCEPT / RELEASE / REJECT / RENEW it - under explicit mode an un-acknowledged record stays in-flight until its acquisition lock expires and is then redelivered.

## Further reading

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