skip to content

Read-Committed Isolation and LSO

3 roadmaps5 questions

How read_committed consumers use the last stable offset and the aborted-transaction index so they never see rolled-back records. Interviewers ask because it explains the latency cost of transactional reads.

part ofApache Kafkaoverview, primer and where to startread it →
on this pageshow

explore

questions

5

What does the consumer setting isolation.level do in Kafka, and what are its two possible values?

level: juniorimportance: must knowfreq 65%

answer

  1. consumer config, not producer
  2. read_uncommitted = default = see everything
  3. read_committed = only committed, no aborted
  4. stalls at LSO while txn open
  5. non-transactional always visible

basics

~10 s

isolation.level controls whether a consumer sees records from in-progress or aborted transactions. read_uncommitted (default) returns all records; read_committed only returns records from committed transactions, hiding aborted and not-yet-committed ones.

solid answer

~40 s

isolation.level is a consumer config that decides how transactional records are surfaced. With read_uncommitted (the default), the consumer reads every record in offset order regardless of transaction state, so it can see records that were later aborted or that belong to an open transaction. With read_committed, the consumer only returns records belonging to committed transactions and never returns aborted records; it also will not return any record beyond the Last Stable Offset (LSO), so it can lag behind the log end while a transaction is still open. Non-transactional records are always visible under both settings. This setting only matters when producers use the transactional API; for plain produces it has no observable effect on which records are returned.

go deeper

for a junior

Know it is a consumer setting with two values and that read_committed hides aborted/uncommitted transactional records.

for a middle

Explain the default, that it only affects transactional data, and that read_committed can stall at the LSO.

for a senior

Tie it to read-process-write pipelines and exactly-once, and explain LSO gating plus aborted-record filtering.

for a principal

Reason about end-to-end EOS guarantees, the latency cost of LSO gating, and when read_uncommitted is acceptable.

## What problem this solves Kafka producers can use **transactions**: a producer with a `transactional.id` opens a transaction with `beginTransaction()`, writes records to one or more topic-partitions, and then either `commitTransaction()` or `abortTransaction()`. Records are physically appended to the log as they are produced — **before** the commit/abort decision is known. That means the log can contain records that ultimately belong to an *aborted* transaction, or records from a transaction that is still *open*. `isolation.level` is the **consumer-side** setting that decides what to do with those records. ## The two values - **`read_uncommitted`** (the default): the consumer returns records in strict offset order, with no regard for transaction outcome. It will hand your application records that are part of an open transaction or that were later aborted. This is the historical/legacy behavior and matches non-transactional Kafka. - **`read_committed`**: the consumer only returns records that belong to **committed** transactions. Records from aborted transactions are filtered out and never delivered. Records from a transaction that has not yet committed are simply **not yet returned** — the consumer waits. ## Key consequences of read_committed 1. **Last Stable Offset (LSO) gating**: a read_committed consumer will not fetch past the LSO — the offset of the first still-open transaction. So consumption can stall at the LSO until that transaction commits or aborts, even though newer records exist in the log. 2. **Aborted records are dropped**: the broker ships an index of aborted transactions with each fetch, and the consumer filters those records out. 3. **Non-transactional records are always visible** under both isolation levels — `isolation.level` only changes how *transactional* data is treated. 4. **Control records** (the commit/abort markers Kafka writes) are never delivered to the application under either setting. ## Default and scope The default is `read_uncommitted` for backward compatibility. If you build read-process-write (exactly-once) pipelines, you almost always set `isolation.level=read_committed` so downstream stages never act on data that was rolled back.

  • What is the default value of isolation.level?
    read_uncommitted, for backward compatibility with non-transactional Kafka behavior.
  • Does isolation.level affect non-transactional records?
    No. Plain (non-transactional) produces are always returned under both settings; the level only changes how transactional records are treated.

saying these in an interview costs you the question

  • Saying isolation.level is a producer config (it is a consumer config).
  • Claiming read_committed is the default (read_uncommitted is).
  • Believing read_committed filters or delays non-transactional records.

context

resolving links…

open as a page

What is the Last Stable Offset (LSO), and how does it gate reads for a read_committed consumer?

level: middleimportance: must knowfreq 55%

basics

~20 s

The LSO is the offset of the first record belonging to a still-open transaction. A read_committed consumer is never allowed to read past the LSO, so it stops there until that transaction commits or aborts.

open as a page

How does a read_committed consumer actually avoid delivering records from aborted transactions?

level: seniorimportance: should knowfreq 35%

basics

~20 s

The broker keeps an aborted-transaction index per segment and sends the relevant aborted (producerId, firstOffset) entries with each fetch. The consumer reads records below the LSO and drops any whose producerId+offset fall inside an aborted transaction's range.

open as a page

What latency and operational trade-offs does isolation.level=read_committed introduce, and how would you mitigate them?

level: seniorimportance: should knowfreq 40%

basics

~10 s

read_committed adds end-to-end latency because consumers can't read past the LSO until a transaction commits, and one long/stuck transaction stalls the whole partition. Mitigate with short transactions, a sane transaction.timeout.ms, and LSO-lag monitoring.

open as a page

When building an exactly-once read-process-write pipeline on Kafka, why is isolation.level=read_committed required on the consuming side, and what breaks if you forget it?

level: principalimportance: should knowfreq 30%

basics

~20 s

Exactly-once needs downstream stages to never act on rolled-back data. read_committed ensures the consumer only sees committed records. With the default read_uncommitted, the consumer processes aborted/uncommitted records, so a rolled-back transaction still leaks downstream, breaking exactly-once.

open as a page