Apache Kafka Deep Dive: Commit Log, Partitions, Consumer Groups & Delivery Guarantees
Kafka's architectural advantage is not speed but immutability — the append-only, partitioned commit log provides ordered replay, durable retention, and independent consumer offset management. Master partition topology, consumer group rebalancing, and exactly-once semantics via the transactional producer API.
Distributed Architecture & System Design
Apache Kafka Deep Dive: Commit Log, Partitions, Consumer Groups & Delivery Guarantees
Every boundary is a failure isolation decision — and nowhere is this more consequential than in how you publish and consume events. The most common failure we see in teams adopting event-driven architecture is treating Kafka as a faster RabbitMQ: they publish messages, consume them once, and move on. They leave enable.auto.commit=true, set a partition count of 1, and never configure acks. Then, when their consumer group restarts during high traffic, they discover that Kafka's rebalance protocol has stopped all partition processing for 45 seconds while a new leader assignment completes — and they have no idea what happened because no one taught them what the commit log model actually is.
Series positioning: This is Part 3 of the Distributed Architecture & System Design series. Building on the inter-service communication paradigms from Part 2: Service-to-Service Communication, it analyzes the mechanics of Apache Kafka's append-only commit log, partition topologies, and consumer groups before exploring AMQP broker routing in Part 4: RabbitMQ Topologies.
1. The Immutable Commit Log
When a consumer reads a message from RabbitMQ, the message is acknowledged and deleted. When a consumer reads a message from Kafka, nothing changes. The message stays on disk, in order, until the configured retention period expires.
Three independent consumer groups read the same immutable log at their own pace. Adding a new consumer group never affects existing consumers.

A Kafka topic is a distributed, durable, ordered file. Producing is an append. Consuming is a read with a bookmark (offset). The file is shared; the bookmarks are independent. This is why Kafka enables event sourcing, CDC, and replay-based debugging — properties that vanish the moment you treat it like a delete-on-read queue.
2. Broker Architecture & Replication
2.1 Leaders, Followers, and ISR
Each partition is stored on one leader broker and replicated to follower brokers. The In-Sync Replica (ISR) set is the subset of followers fully caught up with the leader.
2.2 Durability Configuration
| Scenario | Outcome |
|---|---|
| 1 broker failure (ISR=2, min=2) | Cluster operational ✅ |
| 2 broker failures | NotEnoughReplicas error — producers blocked, data preserved ✅ |
acks=1 + 1 broker failure |
Unacknowledged messages in flight may be lost ❌ |
2.3 KRaft Mode (Kafka 3.x+)
| Aspect | ZooKeeper Mode | KRaft Mode |
|---|---|---|
| Metadata storage | External ZooKeeper ensemble | Internal Kafka Raft log |
| Operational components | Kafka + ZooKeeper | Kafka only |
| Controller failover | Seconds | Sub-second |
| Max partitions (practical) | ~200K | ~1M+ |
3. Partitioning Strategy & Key Design
3.1 Partition Count = Parallelism Ceiling
You cannot scale a consumer group beyond its topic's partition count. Adding a fourth consumer to a three-partition topic leaves it permanently idle. Partition count is a lifetime capacity planning decision — increasing it later may break ordering guarantees for key-based producers.
3.2 Key-Based Ordering
4. Consumer Groups & Rebalancing
4.1 Stop-the-World Rebalance
4.2 Cooperative Incremental Rebalancing
| Rebalance Type | Behavior | Pause Duration |
|---|---|---|
| Eager (default) | All consumers stop and revoke ALL partitions | 5–30s (full group) |
| Cooperative Incremental | Only consumers whose partitions change stop | < 1s |

4.3 Key Consumer Configuration
5. Delivery Guarantee Semantics
5.1 At-Most-Once — Fire and Forget
5.2 At-Least-Once — The Production Default
5.3 Exactly-Once — Transactional API
5.4 Delivery Guarantee Comparison
| Guarantee | Data Loss | Duplicates | Producer Config | Consumer Commit | Overhead |
|---|---|---|---|---|---|
| At-most-once | Possible | Never | acks=0 or acks=1 |
Before processing | Lowest |
| At-least-once | Never | Possible | acks=all, retries |
After processing | Low |
| Exactly-once | Never | Never | idempotent=true + transactionalId |
Inside transaction | ~10–20% throughput |
Exactly-once requires both idempotent producers AND the transactional API. Idempotent producers prevent broker-side duplicates from retries. They do NOT prevent consumer-side duplicates from rebalances. End-to-end exactly-once requires atomic commit of output messages AND input consumer offsets.
6. Producer Configuration Deep Dive
7. Consumer Lag & Dead-Letter Queues
Summary
| Architectural Concern | Production Rule |
|---|---|
| Immutable Commit Log | Kafka never deletes consumed messages; consumer groups maintain independent offsets enabling replay, fan-out, and time-travel. |
| Partition Parallelism | The hard ceiling on consumer group parallelism; set at topic creation based on throughput and ordering requirements. |
| At-Least-Once Delivery | Requires manual offset commit AFTER processing; consumers must be idempotent to handle replays safely. |
| Exactly-Once Semantics | Requires idempotent producers AND transactional APIs; guarantees atomic commit of output messages + input offset. |
| Cooperative Rebalancing | Kafka 2.4+ CooperativeStickyAssignor eliminates stop-the-world pauses by revoking only moved partitions. |
What's Next
Now that we have analyzed Kafka's commit log mechanics, Part 4: RabbitMQ & AMQP Messaging Topologies explores broker-mediated routing, direct/topic/fanout exchanges, quorum queues, and the decision matrix between Kafka and RabbitMQ.
This article was developed with AI-assisted deep search, specification cross-referencing, and technical research synthesis.