Atomicity and Consistency Across Databases and Messaging Systems
summary
Explains a concrete implementation: write events into an outbox table in the same DB transaction, run a scheduled sender that polls and publishes to brokers (Kafka, RabbitMQ, ActiveMQ), and mark events sent; this guarantees DB-and-queue atomicity but allows duplicates and delivery delay. Describes an emergency drop variant where the app tries to publish after commit and the job is a fallback (claims ~99.9% native sends). Recommends idempotency on receiver; treats distributed transactions discouraged for scalable cloud systems.
AI-written summary · about
chapters (7)
- 0:00Introduction and agenda
- 1:30Problem of atomicity in databases
- 5:49Classical outbox pattern explained
- 14:13Emergency drop variation
- 24:05Pros and cons comparison
- 24:46When to use outbox pattern
- 25:52Q&A session
related talks
01h 02mAt Least Once
01h 01mBeyond Pub/Sub - Advanced Messaging Patterns
01h 02mConsistency and Agreements in Distributed Systems
01h 03mBeyond Pub/Sub - Advanced Messaging Patterns
18mGuaranteed messages delivery:Challenges of transactional Outbox & Inbox patterns
53mEffective Microservice Communication and Conversation Patterns
47mReliably Sending Events to Apache Kafka: From CDC to the Transactional Outbox Pattern
56mFrom Unreliable to Resilient: Mastering Distributed Systems