# Kafka Flow concepts guide > A plain-language guide to the Kafka concepts shown in Kafka Flow: producers, acknowledgments, partitions, replicas, ISR, high watermarks, consumer groups, and share groups. Kafka Flow is a deterministic teaching simulation, not a Kafka broker or a capacity-planning tool. It separates producer acknowledgement, follower replication, high-watermark advancement, and consumer visibility so their different timing is visible. [Open the interactive visualization](https://kafka-flow.com/) ## Producer A producer sends records to a Kafka topic. A record key usually determines the partition, and the producer writes to that partition's leader. Real producers can buffer and batch records, so multiple sends may be in flight at once. A card leaves this rail when its request settles, and one that settled badly carries a letter as it goes: F the broker rejected every attempt, U the leader changed before the acknowledgment arrived so the producer never learned the outcome, and L the record was acknowledged and then lost in an election. Only F is a clean failure. U is the case a producer cannot tell apart from success on its own, which is what idempotent producers and transactions exist to close, and L is the one where the client was told the right thing at the time. ## Acks Acks controls when Kafka completes a producer request. Consumer visibility follows the partition's high watermark instead. 0 requests no broker response, 1 waits for the leader to append the record, and All waits for every replica in the current ISR. An acknowledgment is not durability, and 1 is where the two come apart. The leader answers as soon as it has appended, before any follower has copied the record, so a leader that fails in that gap takes the only copy with it: the replica elected in its place truncates to its own log end offset, and a record the producer was told had landed is simply not there. Nothing retries it, because as far as the producer is concerned it succeeded. That is the record the rail marks L on its way out. ## In-Flight Requests max.in.flight.requests.per.connection caps how many produce requests a producer may have outstanding at a time; Kafka's default is 5. Kafka applies the cap per broker connection, so a producer writing to several leaders gets that many to each. This visualization applies one shared budget across the producer instead, so a single record can be followed end to end. At 1 each request settles before the next is sent, so one record walks every protocol stage alone. Above 1 the leader can append ahead of a lagging follower, which is what lets an unreplicated backlog build up and become visible. ## Partitions A partition is an ordered, append-only log and Kafka's unit of replication and parallelism; offsets and ordering apply within one partition. A record key usually routes matching records to the same partition. Adding partitions can remap future keyed records but does not redistribute existing records. ## Replicas Replicas are copies of a partition stored on different brokers; one is the leader, while followers copy its ordered log and can lag behind. The replication factor includes the leader and every follower. The ISR contains the replicas that are currently in sync. ## Minimum In-Sync Replicas (Min ISR) Min ISR sets the minimum number of in-sync replicas, including the leader, required to accept an Acks=All write; it does not set the acknowledgment count. It also holds the partition's commit boundary. While the ISR is below the floor the leader stops advancing the high watermark, so already-appended records stay invisible to consumers whatever Acks is set to — raising Min ISR can stall delivery even at Acks=0 or 1. After admission, Acks=All waits for every replica in the current ISR. This visualization uses standard ISR behavior without ELR. ## Replica Lag Maximum Kafka's replica.lag.time.max.ms is how long a follower may go without catching up to the leader's log end offset before the leader removes it from the ISR. This visualization measures the same thing in simulation beats. A lagging replica still inside the ISR holds back the high watermark, so producers waiting on Acks=All and consumers waiting on visibility both slow to its pace. Removing it restores the partition's speed at a lower replication level, and it rejoins once it reaches the high watermark again. The clock is only refreshed by a fetch that reaches the leader's log end offset, so a follower whose fetcher has stopped never resets it and this maximum is the countdown to its eviction. What resets it is the offset the follower asked from, not the one it ends up holding: a replica coming back from a pause asks from where it stopped, so even the fetch that closes its whole gap is credited to its previous one and it is still behind on the clock for that beat. ## Brokers A broker is a Kafka server that stores partition replicas and serves client requests; each partition has one leader, while followers on other brokers copy its log. Adding a broker does not move replicas on its own. Kafka needs a reassignment, which this visualization starts automatically. ## Consumers A consumer fetches records from its assigned partitions without removing them from Kafka. Its position tracks the next offset to fetch, while its committed offset provides the recovery checkpoint used after a restart or rebalance. ## Consumer Group Consumers with the same group ID act as one logical subscriber. Kafka assigns each subscribed partition to one member, while separate groups read the topic independently. Membership or partition changes trigger a rebalance. In a consumer group each partition has exactly one owner, so member count above partition count adds no parallelism; a share group hands the same partition to several members instead. ## Share Group A share group is Kafka's queue-style subscription, introduced by KIP-932 as queues for Kafka. Kafka assigns each partition to ceil(members / partitions) members, so a share group whose member count is at or below the partition count assigns just as exclusively as a consumer group. Sharing appears exactly when consumers outnumber partitions: the member a consumer group would leave idle joins a partition that already has an owner. That buys consumption which scales past the partition count and retry at the granularity of a single record. It costs per-partition ordering, because several members read one log at the same time and finish out of order. Progress is not a single committed offset. A share group holds a window of per-record acknowledgements per partition, and the window base moves only across a contiguous run of finished records. One unacknowledged record holds the base in place while later records keep being delivered past it. On the broker lanes each record carries one small mark per share group watching it, and its shape says which kind of thing it is. A squared mark is a delivery still in play and its numeral is the delivery count: filled in a member's colour while that member holds the record, outlined in ink once it has come back and is waiting to be handed out again. A round mark is a group's verdict and carries the group's label instead, in the finishing member's colour for acknowledged and in the offline red for archived. Hovering any of them explains it. The group's window base is the labelled marker on the lane itself, and everything behind it is finished. ## Acquisition Lock Fetching a record in a share group acquires it: the record is marked as held by that member for group.share.record.lock.duration.ms, which Kafka defaults to 30 seconds. This visualization measures the same thing in simulation beats. No other member is given the record while the lock holds. If the member neither acknowledges the record nor renews the lock before it drains, the record becomes available again and is delivered to whoever asks next. A consumer that crashes mid-record therefore needs no cooperation and no offset commit for its work to be retried. One simplification is worth naming. In Kafka whether a record is acknowledged is a property of the processing; here it is a property of the record. Records under one key need a second delivery before they are acknowledged, and about one record in twenty is never acknowledged at all, so the same story replays on every run and the key legend can isolate it. ## Delivery Count Kafka counts a record's deliveries and archives it instead of redelivering it once the count reaches group.share.delivery.count.limit, which Kafka defaults to 5. This visualization defaults to 3 so the sequence stays watchable, and measures the same count. The count increments when the record is handed out, not when a delivery fails. It answers how many times the record has been delivered, so a record acquired once carries a count of one whether or not anything went wrong with it. An archived record is never delivered again. That is what stops one unprocessable record from blocking a queue forever: the window base moves past it, and the members that kept picking it up return to the rest of the partition. It keeps its mark on the record afterwards, because a record the group gave up on is not the same as one it never reached. ## Scope and simplifications - The simulation focuses on the record path, replication, ISR behavior, consumer groups, and share groups. - It intentionally leaves out transactions, eligible leader replicas, unclean leader election, and advanced retry timing. - Time-based broker settings are represented as deterministic simulation ticks so behavior can be stepped backward and forward. - Producer concurrency uses one shared budget in the visualization; Kafka applies max.in.flight.requests.per.connection per broker connection. ## Primary sources - [Apache Kafka documentation](https://kafka.apache.org/documentation/) - [Apache Kafka producer configuration](https://kafka.apache.org/documentation/#producerconfigs) - [KIP-932: Queues for Kafka](https://cwiki.apache.org/confluence/spaces/KAFKA/pages/255070434/KIP-932%2BQueues%2Bfor%2BKafka)