“Update the database and publish to Kafka” cannot be atomic across two systems — one can succeed while the other fails. The outbox pattern writes the event to an outbox table inside the same local transaction as the business data; a relay (poller or CDC) then publishes it. At-least-once delivery with no phantoms, so consumers stay idempotent.
Worked example: to dodge the dual-write problem, write the event into an ‘outbox’ table inside the same DB transaction as the data change; a relay publishes it after commit — one atomic source of truth. Gotcha: delivery is at-least-once (relay may publish then crash before marking sent), so consumers must be idempotent, and the outbox needs cleanup so it does not grow forever.