What You Will Learn

• What is Outbox Pattern?
• Why Outbox is Needed
• Dual Write Problem
• Transactional Messaging
• Outbox Table Design
• Kafka Integration
• CDC (Change Data Capture)
• Debezium Integration
• Spring Boot Example
• Banking Use Cases
• Enterprise Architecture
• Interview Questions

---

Introduction

Modern Microservices often need to:

Update Database

AND

Publish Event

Example:

Create Order

↓

Save Order

↓

Publish OrderCreated Event

Simple?

Not really.

---

The Dual Write Problem

Imagine:

Step 1: Save Order

Step 2: Publish Kafka Event

What if:

Database Save Success

Kafka Publish Failure

Result:

Order Exists

But Event Missing

System becomes inconsistent.

---

Example Failure Scenario

flowchart LR

A[Save Order]

B[Database Success]

C[Publish Event]

D[Kafka Failure]

A --> B
B --> C
C --> D

Data inconsistency occurs.

---

Another Failure Scenario

Kafka Event Published

Database Transaction Rolled Back

Result:

Event Exists

Order Does Not Exist

Again inconsistent.

---

What is Outbox Pattern?

Outbox Pattern guarantees:

Database Update

AND

Event Creation

In Same Transaction

---

Purpose of Outbox Pattern

Primary Goal:

Reliable Event Publishing

Without:

Distributed Transactions

---

Traditional Approach

flowchart LR

A[Application]

B[Database]

C[Kafka]

A --> B
A --> C

Two separate writes.

Dangerous.

---

Outbox Solution

flowchart LR

A[Application]

B[Business Table]

C[Outbox Table]

A --> B
A --> C

Both writes occur in same transaction.

---

Core Idea

Instead of:

Save Order

Publish Kafka Event

Do:

Save Order

Save Event In Outbox Table

Then publish later.

---

Outbox Architecture

flowchart LR

A[Application]

B[Business Table]

C[Outbox Table]

D[Kafka Publisher]

E[Kafka]

A --> B
A --> C

C --> D

D --> E

---

Order Creation Example

Business Data:

Order Created

Outbox Event:

OrderCreated Event

Stored together.

---

Transaction Flow

flowchart LR

A[Create Order]

B[Save Order]

C[Save Outbox Event]

D[Commit]

A --> B
B --> C
C --> D

Single database transaction.

---

Database Tables

Orders Table

ORDERS
------------------

ID

CUSTOMER_ID

AMOUNT

STATUS

---

Outbox Table

OUTBOX
------------------

ID

EVENT_TYPE

PAYLOAD

STATUS

CREATED_AT

---

Outbox Table Example

ID: 100

EVENT_TYPE:
OrderCreated

STATUS:
NEW

---

Outbox Record Example

{
  "eventType":"OrderCreated",
  "orderId":"100",
  "customerId":"123",
  "amount":500
}

---

Workflow Overview

flowchart LR

A[Order Service]

B[Orders Table]

C[Outbox Table]

D[Publisher]

E[Kafka]

A --> B
A --> C

C --> D

D --> E

---

Step 1

Create Order.

---

Step 2

Insert Order Record.

---

Step 3

Insert Outbox Event.

---

Step 4

Commit Transaction.

---

Step 5

Publisher Reads Outbox.

---

Step 6

Publish Event To Kafka.

---

Step 7

Mark Event Processed.

---

Complete Flow

flowchart LR

A[Create Order]

B[Save Order]

C[Save Outbox Event]

D[Commit]

E[Publisher]

F[Kafka]

G[Mark Processed]

A --> B
B --> C
C --> D
D --> E
E --> F
F --> G

---

Spring Boot Example

Order Entity

@Entity
public class Order {

    @Id
    private Long id;

    private Double amount;
}

---

Outbox Entity

@Entity
public class OutboxEvent {

    @Id
    private Long id;

    private String eventType;

    private String payload;

    private String status;
}

---

Transactional Save

@Transactional
public void createOrder() {

    orderRepository.save(order);

    outboxRepository.save(
        outboxEvent
    );
}

Both saved together.

---

Why This Works

Either:

Both Saved

or

Both Rolled Back

No inconsistency.

---

Publisher Service

@Scheduled(fixedDelay = 5000)
public void publishEvents() {

   List<OutboxEvent> events =
       repository.findPending();

   // Publish To Kafka
}

---

Publisher Flow

flowchart LR

A[Outbox Table]

B[Publisher]

C[Kafka Topic]

A --> B
B --> C

---

Event Status Tracking

Common statuses:

NEW

PROCESSING

PUBLISHED

FAILED

---

Status Lifecycle

flowchart LR

A[NEW]

B[PROCESSING]

C[PUBLISHED]

A --> B
B --> C

---

Kafka Integration

Outbox publisher sends:

OrderCreated

OrderUpdated

OrderCancelled

to Kafka topics.

---

Kafka Architecture

flowchart LR

A[Outbox Table]

B[Publisher]

C[Kafka]

D[Consumers]

A --> B
B --> C
C --> D

---

CDC (Change Data Capture)

Instead of polling:

SELECT * FROM OUTBOX

Use CDC.

---

What is CDC?

CDC monitors database changes automatically.

Example:

New Row Inserted

↓

Capture Change

↓

Publish Event

---

CDC Flow

flowchart LR

A[Database]

B[CDC Engine]

C[Kafka]

A --> B
B --> C

---

Debezium

Most popular CDC tool.

Features:

MySQL

PostgreSQL

Oracle

SQL Server

integration.

---

Debezium Architecture

flowchart LR

A[Database]

B[Debezium]

C[Kafka]

D[Consumers]

A --> B
B --> C
C --> D

---

Banking Example

Fund Transfer.

Workflow:

Debit Account

Save Event

Publish Transfer Event

---

Banking Architecture

flowchart LR

A[Transfer Service]

B[Account Table]

C[Outbox Table]

D[Kafka]

A --> B
A --> C

C --> D

---

Insurance Example

Claim Submission.

Workflow:

Create Claim

Store Event

Publish ClaimCreated

---

Insurance Flow

flowchart LR

A[Claim Service]

B[Claims Table]

C[Outbox Table]

D[Kafka]

A --> B
A --> C

C --> D

---

Retail Example

Order Placement.

Workflow:

Create Order

Store Event

Notify Inventory Service

---

Retail Architecture

flowchart LR

A[Order Service]

B[Orders]

C[Outbox]

D[Kafka]

E[Inventory Service]

A --> B
A --> C

C --> D
D --> E

---

Outbox vs Direct Kafka Publish

Feature	Direct Publish	Outbox
Reliability	Low	High
Consistency	Risky	Strong
Transaction Safe	No	Yes
Enterprise Ready	Limited	Yes

---

Outbox vs Two Phase Commit

Feature	Outbox	2PC
Performance	High	Lower
Scalability	High	Lower
Complexity	Medium	High
Cloud Native	Yes	No

---

Enterprise Use Cases

Banking

Fund Transfers

Account Events

Audit Events

---

Insurance

Claims

Policy Updates

Premium Payments

---

Retail

Orders

Inventory Updates

Shipping Events

---

Healthcare

Patient Registration

Appointment Events

---

Travel

Booking Events

Payment Events

---

Real Enterprise Architecture

flowchart LR

A[Client]

B[API Gateway]

C[Order Service]

D[Orders DB]

E[Outbox Table]

F[Debezium]

G[Kafka]

H[Consumers]

A --> B
B --> C

C --> D
C --> E

E --> F

F --> G

G --> H

---

Benefits

✅ Reliable Event Publishing

✅ Prevents Dual Write Problem

✅ Database Consistency

✅ Kafka Friendly

✅ Cloud Native

✅ Works With CDC

✅ Enterprise Proven

---

Limitations

❌ Additional Table

❌ More Components

❌ Publisher Maintenance

❌ Eventual Consistency

---

When To Use Outbox Pattern

Use when:

Microservices

Kafka Integration

Event Driven Systems

Reliable Messaging Required

Distributed Architectures

---

When NOT To Use

Avoid when:

Simple CRUD Applications

No Messaging

Monolithic Internal Tools

---

Interview Questions

What is Outbox Pattern?

A pattern that stores business data and events in the same database transaction.

---

What Problem Does It Solve?

Dual Write Problem.

---

What is Dual Write?

Writing to database and Kafka separately.

---

Why Use Outbox?

To guarantee consistency between data and events.

---

What is CDC?

Change Data Capture.

---

Popular CDC Tool?

Debezium

---

Can Outbox Work Without Kafka?

Yes.

Any message broker can be used.

---

Biggest Benefit?

Reliable event publishing.

---

Key Takeaways

• Outbox Pattern solves the Dual Write Problem.
• Business data and events are stored in the same transaction.
• Kafka publishing happens asynchronously.
• Frequently combined with CDC and Debezium.
• Widely used in Banking, Insurance, Retail, Healthcare, and Travel platforms.
• One of the most important patterns in Event-Driven Microservices Architecture.
• Essential for building reliable distributed systems.

---