A Kafka transaction groups a stream-processing operation so a service can read an event, process it, and publish related results atomically. This addresses the architectural risk of partial downstream updates when failures or retries occur. section 7.4.2
Unlike a general database transaction, Kafka transactions target read-process-write applications. Their central guarantee is exactly-once processing: outputs appear once even when the service fails or retries, rather than exposing duplicated or skipped results. section 7.4.2
Order processing
An OrderService reads an event from ORDERS and produces corresponding events to SHIPMENTS, BILLING, and INVENTORY. A transaction keeps these effects together, preventing one downstream topic from receiving an update while another misses it. section 7.4.2
A Kafka transaction is useful when:
- A single input event must produce a consistent set of outputs across multiple topics. section 7.4.2
- Retries or service failures could otherwise duplicate results or leave downstream data incomplete. section 7.4.2
- Consumers need isolation choices that determine whether uncommitted messages are visible. section 7.4.2
Figure 7.24 OrderService reads, processes, and writes each event atomically.
Use the event-flow diagram to trace one input through processing and atomic publication of its results. section 7.4.2
