Scenario 00.1.2 · One record, end to end

Kafka write path: one record from producer to consumer

Anatomy · Beginner · about 1 min · Apache Kafka 4.3

Follow a single record producer → leader log → replicated & committed → consumer.

What you start with

This traces one record through Kafka's full write path: a producer sends it, the partition leader appends it to its log, followers replicate it, the high watermark advances to mark it committed, and a consumer finally reads it.

Step by step

1. Cluster ready · idle t+0.000s Three brokers, three racks, RF=3, min.ISR=2. Press ▶ to advance. Open at this step: step 1, Cluster ready · idle
2. Producer batches t+0.900s Open at this step: step 2, Producer batches
3. Leader append · uncommitted t+1.400s Leader appended at offset 0. Followers haven't fetched yet, so HW stays at 0. Open at this step: step 3, Leader append · uncommitted
4. Replicated · HW advances · ack t+2.000s Open at this step: step 4, Replicated · HW advances · ack
5. Consumer reads the record t+2.800s Consumer polls and reads offset 0 - its read position advances to 1. Auto-commit runs inside a later poll (real Kafka waits for auto.commit.interval.ms, 5 s by default), so the committed offset still trails by one (lag 1). Open at this step: step 5, Consumer reads the record
6. Consumer commits · caught up · lag 0 t+3.200s A later poll auto-commits offset 1 (the simulator commits on the very next poll), so committed now equals the read position. The record is fully end to end and the consumer sits at lag 0. Open at this step: step 6, Consumer commits · caught up · lag 0

The takeaway

Every write follows the same lifecycle - produce → leader append → replicate → commit → consume - and that backbone underlies every later scenario.

Configs in this scenario

• min.insync.replicas The fewest in-sync replicas, leader included, that must have a write for an acks=all produce to succeed (default 1); with fewer in the ISR the leader rejects the write with NOT_ENOUGH_REPLICAS. How min.insync.replicas works
• auto.commit.interval.ms How often a consumer with enable.auto.commit=true commits its offsets (default 5000, 5 seconds); records processed after the last commit are read again after a crash.

Embed this scenario

Paste this into a blog post, a course page or your team's docs. The scenario plays inside your page, and the link under it points readers to this walkthrough.

<iframe src="https://monedula.dev/kafka-simulator/embed/?scenario=00.1.2" title="Kafka Simulator: One record, end to end" width="100%" height="520" style="border:1px solid #d0d0d0;border-radius:8px" loading="lazy"></iframe>
<p><a href="https://monedula.dev/kafka-simulator/scenarios/write-path/">Kafka write path: one record from producer to consumer</a></p>

Further reading

Apache Kafka documentation

More in Anatomy

• Kafka topics, partitions and offsets explained
• Kafka message keys: how a key picks the partition
• Kafka offsets are per partition, not global
• Kafka replication factor, leader and follower replicas
• Kafka high watermark vs log end offset (LEO)
• Why Kafka consumers cannot read past the high watermark
• Kafka log start offset: why the earliest offset is not 0

All scenarios