Kafka reliability / Transaction lab
Kafka Transactions & Visibility Lab
Which records and offsets are committed or visible, and what should you conclude if transaction completion is uncertain?
Baseline: apache-java-4.3.1 · source 26b251a451ce
This deterministic teaching model runs in your browser and never connects to Kafka. It accepts only bounded synthetic controls. Curated scenario and variant IDs may appear in a shareable URL; custom local values, payloads, brokers, credentials, and production identifiers never do. Exports include only what you request.
Deterministic teaching model · apache-java-4.3.1
T05: An open transaction blocks later ordinary data
Why can replicated data remain hidden from read_committed?
Current outcome · step 0 of 4
No transaction has begun. LEO, HW, and LSO all start at the same exclusive boundary.
Default synthetic example loaded.
Log and visibility
- Partition 0
- LEO 10 / HW 10 / LSO 10
- 0 visible application record(s) under read_committed.
Transaction coordinator
- Decision
- undecided
- Participant markers
- none
- Producer knowledge
- UNKNOWN
- Response
- none
Input progress and effects
- Fetched / stored next offset
- 10 / 10
- Pending offset
- none
- No unresolved checkpoint.
- Processing attempts
- 1
- External effects
- 0
Invariant results
logStart ≤ LSO ≤ HW ≤ LEO
holds in model
Every modeled partition preserves exclusive offset-boundary order.
Control and aborted records stay out of read_committed output
holds in model
Application projection excludes control records and committed-only projection excludes aborted data.
Abort recovery restores fetched input position
not applicable
This trace did not abort.
Kafka terminal state retracts external effects
not applicable
No external effect was dispatched in this trace.
Ordered trace
The state table shows model truth. Each observer result says what the current caller can establish at that step.
| Step | Actor | Action | Observer result |
|---|---|---|---|
| 10 ms | application | Begin transaction locally | beginTransaction changes local producer state; it does not contact the broker or commit anything. |
| 25 ms | producer | Append transactional data to partition 0 | Transactional data is appended at offset 10; send acknowledgement is not transaction completion. |
| 36 ms | ordinary producer | Append ordinary data behind the open transaction | A separate ordinary writer appends data at offset 11. |
| 410 ms | replicas | Replicate both records | Partition 0 reaches HW 12; transactional stability remains a separate boundary. |
Evidence and limits
Assumptions and known limits
- Ordinary transaction protocol v2 with transaction.two.phase.commit.enable=false.
- Coordinator decision, participant marker stability, caller knowledge, and external effects are separate state.
- No XA engine, two-phase extension runtime, complete coordinator recovery, or cross-partition snapshot protocol.
One decision does not mean one visibility instant
The model keeps coordinator decision, per-partition marker append, marker stability, LSO, pending group progress, and producer knowledge separate. It uses exclusive offset boundaries and never exposes control records as application data. Ordinary commit or abort response loss repeats the same terminal operation; it does not choose a new outcome.
Assumptions and limits
- Feature levels, protocol versions, client settings, and binary versions remain separate facts.
- Replication examples use stable committed ISR membership between declared transitions.
- The ordinary transaction profile disables transaction.two.phase.commit.enable.
- Browser traces are deterministic teaching models, not broker observations or production recommendations.