Kafka reliability / Effects workbench
Kafka Effects, Outbox & Inbox Workbench
Which atomic unit protects this business operation when publication or processing repeats?
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
E03: Inbox claim and DB mutation commit together
Can two concurrent deliveries apply the mutation twice?
Current outcome · step 0 of 6
No source transaction, Kafka publication, consumer progress, or business effect exists yet.
Default synthetic example loaded.
Source transaction
- Business change
- absent
- Outbox intent
- absent
- Recovery path
- declared
- Relay progress
- 0
Kafka publication and progress
- Publication occurrences
- 0
- Consumer deliveries
- 0
- Stored next offset
- 10
- Ordering
- partition-local fixture
Sink identity and effect
- Protected unit
- business-operation
- Committed inbox claims
- 0
- DB / provider effects
- 0 / 0
- Caller provider knowledge
- UNKNOWN
- Identity conflicts
- 0
Invariant results
Source business change and outbox intent share a local transaction
holds in model
The reducer commits or omits both local rows together.
The selected local identity protects at most one DB mutation
holds in model
Committed unique identity and DB mutation remain one local transaction.
The provider contract protects at most one effect
not applicable
No external provider is selected.
A mismatching intent is never silently treated as a duplicate
holds in model
No conflicting fingerprint was reused.
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 | source database | Commit business change and outbox intent | The source transaction atomically commits the business change and outbox intent. |
| 210 ms | relay | Publish outbox event to Kafka | Kafka publication occurrence 1 is acknowledged in the teaching trace. |
| 320 ms | consumer | Deliver the Kafka event to attempt A | Consumer delivery 1 carries event event-a, operation operation-a, and source offset 10. |
| 430 ms | consumer A | Attempt A stages operation identity | Attempt attempt-a stages inbox identity operation-a; neither the claim nor DB mutation is committed yet. |
| 531 ms | consumer B | Attempt B races for the same identity | A concurrent attempt already stages the unique identity. Only one local transaction can win. |
| 640 ms | source database | Attempt A commits identity and DB mutation | The inbox identity, local DB mutation, and stored result commit in one local transaction. |
Evidence and limits
Assumptions and known limits
- Synthetic event, operation, and aggregate identities remain separate.
- A local database transaction cannot roll back an already completed external effect.
- No SQL isolation scheduler, provider, CDC connector, schema registry, or compensation engine runs in the browser.
Kafka cannot roll back a transaction it does not own
The workbench separates source DB commit, outbox intent, Kafka publication occurrence, consumer delivery, inbox identity, local DB mutation, provider effect, caller receipt, and group progress. Event identity and business-operation identity are independent. Retention and semantic fingerprint checks decide whether a repeated attempt can reuse a prior result.
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.