https://devops-monk.com/tags/outbox-pattern/Recent content in Outbox-Pattern on Devops MonkHugoen-usSun, 03 May 2026 00:00:00 +0000https://devops-monk.com/2026/05/spring-boot-kafka-transactional-outbox/Sun, 03 May 2026 00:00:00 +0000https://devops-monk.com/2026/05/spring-boot-kafka-transactional-outbox/Publishing an event to Kafka after saving to the database looks simple. It has a subtle, dangerous flaw: if the Kafka publish fails after the DB commit, or the app crashes between the two, your event is lost and your data is inconsistent. The Transactional Outbox Pattern solves this by writing the event to the database in the same transaction as the business data, then publishing to Kafka separately. This guide covers the pattern, the implementation, and idempotent consumers.https://devops-monk.com/tutorials/spring-boot/spring-boot-kafka-outbox-pattern/Sun, 03 May 2026 00:00:00 +0000https://devops-monk.com/tutorials/spring-boot/spring-boot-kafka-outbox-pattern/There is a fundamental problem with publishing Kafka events after a database commit: if the application crashes between the commit and the publish, the event is lost forever. The Transactional Outbox Pattern solves this. The Problem @Transactional public Order createOrder(CreateOrderRequest request) { Order order = orderRepository.save(buildOrder(request)); // DB committed ✓ kafkaTemplate.send("order-events", event); // ← Crash here → event lost, DB already committed // → Inventory never updated, customer never notified return order; } Two distributed systems (PostgreSQL and Kafka) can’t be in a single transaction.