The latest articles on DEV Community by Denis Toropov (@denis_toropov_41dbbe80185). https://dev.to/denis_toropov_41dbbe80185 https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3951276%2F81e2d775-315a-4bbf-b424-898ec9b14e2f.png https://dev.to/denis_toropov_41dbbe80185 en Denis Toropov Thu, 11 Jun 2026 19:07:00 +0000 https://dev.to/denis_toropov_41dbbe80185/transactional-outbox-with-kafka-how-to-stop-losing-events-when-syncing-databases-4nbm https://dev.to/denis_toropov_41dbbe80185/transactional-outbox-with-kafka-how-to-stop-losing-events-when-syncing-databases-4nbm <h1> Transactional Outbox with Kafka: How to Stop Losing Events When Syncing Databases </h1> <p>When you sync data between services (or databases) through Kafka, the classic failure looks like this: <strong>the database transaction commits, but the Kafka message never gets published</strong> (crash, network issue, timeout). Your systems diverge silently, and you only discover it when a user reports incorrect data.</p> <h2> Why the obvious fixes don’t work </h2> <p>Wrapping Kafka send in retries doesn’t guarantee delivery if the process dies after the DB commit. Sending to Kafka <em>before</em> committing the DB creates “phantom events” about changes that never made it into the database. Two-phase commit is usually too complex operationally and doesn’t fit Kafka in a clean, universal way.</p> <h2> The key idea </h2> <p>Make the critical operation <strong>one atomic DB transaction</strong>: write the business data <em>and</em> the event to an <code>outbox</code> table in the same commit. If the update exists, the event exists too.</p> <p>Conceptually:</p> <ul> <li><p>In one DB transaction: update domain tables + <code>INSERT</code> into <code>outbox</code></p></li> <li><p>Later: a separate mechanism reads <code>outbox</code> and publishes to Kafka</p></li> <li><p>This makes delivery retryable because the event is durably stored</p></li> </ul> <h2> Two ways to deliver events from the outbox </h2> <h3> 1) Polling Relay </h3> <p>A background worker polls unsent rows (<code>sent_at IS NULL</code>), publishes them to Kafka, then marks them as sent. It’s simple, reliable, and often enough when sub-second latency isn’t a strict requirement. If you run multiple workers, you must ensure each event is claimed once (typically via row locking / “skip locked” patterns).</p> <h3> 2) CDC via Debezium </h3> <p>Instead of polling, Debezium streams inserts from the database transaction log (WAL) to Kafka. This reduces latency and removes the need for a poller, but adds infrastructure/ops complexity (Debezium + Kafka Connect).</p> <h2> Don’t forget: duplicates will happen </h2> <p>Outbox pipelines are typically <strong>at-least-once</strong>, so consumers must be idempotent. The most robust approach is an <code>inbox</code> table with a <strong>unique constraint on <code>event_id</code></strong>: first insert the event id; if it already exists, skip processing. This avoids race conditions that occur with “check then insert”.</p> <h2> Common pitfalls </h2> <p>If you run the relay inside every API instance, scaling your API can accidentally scale polling load and hammer the DB. Also, outbox/inbox tables will grow—plan retention/cleanup. Finally, monitor lag: the count of unsent events and the age of the oldest unsent event are simple, high-signal metrics.</p> <h2> Bottom line </h2> <p><strong>Transactional Outbox</strong> prevents “DB committed but event lost” by making event creation part of the DB transaction, then reliably delivering events to Kafka via polling or CDC—while consumers protect themselves with idempotency.</p> architecture database distributedsystems systemdesign