Back to Catalog
Integration
Messaging Endpoints
Transactional Client
Send messages as part of a DB transaction — both commit or both roll back.
Intent & Description
Real-world Use Case
Order Service updates order status to CONFIRMED in the DB and sends an OrderConfirmed message to the broker — both in one transaction. If anything fails, the rollback undoes both. No orphaned messages, no silent data inconsistency.
Source
📌 TL;DR
Transactional Client = send messages only if the DB transaction commits. Atomic consistency without dual-write risk. In practice — implement this via Transactional Outbox pattern.
Advantages
- Atomic consistency between state change and message publishing
- No dual-write problem — one transaction governs both
- Prevents orphaned messages (message sent but DB write failed)
- Prevents lost messages (DB write succeeded but message never sent)
Disadvantages
- True distributed transactions (XA) are slow and operationally complex
- Transactional Outbox is the preferred modern alternative — adds its own complexity
- Not all brokers support transactional message sending
- Performance overhead from transaction coordination