Managing Distributed Transactions in Microservices: 2PC, Saga, Kafka

Md Mahadi Hasan — Thu, 10 Sep 2026 14:45:19 +0000

Why a normal database transaction is not enough when an order crosses multiple services
Imagine that we are building an e-commerce application with three microservices:

OrderService creates and manages orders.
PaymentService charges customers and processes refunds.
InventoryService reserves and releases products.

At first, the order flow looks like simple:

Create the order.
Charge the customer’s card.
Update the inventory.
Confirm the order.
But what happens if the payment succeeds and the product is out of stocks? What happens if the database transaction succeeds but the application crashes the infomation before it publishes an event to Kafka?

These questions actually have made the distributed transactions become interesting and difficult.

In this article, I will use the order workflow to explain local database transactions, Two-Phase Commit (2PC), Saga choreography, Saga orchestration, and the Transactional Outbox pattern.

Starting with a familiar database transaction

If all the operations belong to one application and use the same database, we might write something like this:

transaction = database.begin()
try:
    createOrder()
    chargeCard()
    updateInventory()
    transaction.commit()
except:
    transaction.rollback()

This is a normal local ACID transaction. Either every database operation is committed, or every operation is rolled back.

The approach works when all the changes are controlled by the same transaction manager. It stops working whenOrderService, PaymentService, and InventoryService has separate databases system.

Rolling back the OrderService database cannot automatically:

Undo a record committed by PaymentService.
Restore inventory changed by InventoryService.
Reverse a charge made through an external payment provider.
This is the first important distinction- wrapping several service calls inside try/catch block does not create a distributed transaction.

How Two-Phase Commit works

Two-Phase Commit attempts to make one transaction atomic across multiple participating resources. A transaction coordinator manages the process in two phases.

Phase 1: Prepare
The coordinator asks every participant whether it is ready to commit:

Coordinator -> Order database: Prepare
Coordinator -> Payment database: Prepare
Coordinator -> Inventory database: Prepare

Each participant performs the required work without making the final commit. It normally keeps the relevant resources locked and responds with either “ready” or “failed.”

Phase 2: Commit or rollback
If every participant is ready, the coordinator instructs all of them to commit. If any participant cannot prepare, the coordinator tells all participants to roll back.

2PC can provide strong consistency, but it comes with tradeoffs:

Participants may hold locks while waiting for the coordinator.
A coordinator or network failure can leave transactions blocked.
Services become more tightly coupled at the transaction level.
Every resource must support the distributed transaction protocol.
An external payment gateway will usually not participate in our database transaction.
Because of these limitations, 2PC is often a difficult fit for independently deployed microservices. It may still make sense in controlled environments with compatible resources and a strong consistency requirement, but it should not be our automatic choice.

Saga: a sequence of local transactions

The Saga pattern approaches the problem different way. Instead of trying to create one transaction across all services, it breaks the business workflow into multiple local transactions.

Each service commits its own change. If a later step fails, the system runs compensating actions to logically reverse the work already completed.

For our order workflow, the transactions and compensations might look like this:

A compensation is not the same as a database rollback. A refund is a new business transaction. It does not erase the original charge however it creates another financial operation that reverses its effect.

This also means a Saga provides eventual consistency. For a short time, one service may show a successful payment while another is still attempting to reserve the inventory.

There are two common ways to coordinate a Saga- choreography and orchestration.

Saga choreography with Kafka
In choreography, there is no central component controlling the entire workflow. Each service listens for relevant events, performs its local transaction, and publishes the next event.

The successful flow might be:

OrderService
    creates a PENDING order
    publishes OrderPlaced
PaymentService
    consumes OrderPlaced
    charges the customer
    publishes PaymentSucceeded
InventoryService
    consumes PaymentSucceeded
    reserves the products
    publishes InventoryReserved
OrderService
    consumes InventoryReserved
    marks the order as CONFIRMED

Kafka topics carry facts about things that have already happened. Event names such as OrderPlaced, PaymentSucceeded, and InventoryReserved make those facts clear.

If payment fails, then?

If the card is declined, PaymentService publishes PaymentDeclined. OrderService consumes that event and cancels the order.

OrderPlaced
    -> PaymentDeclined
    -> OrderCancelled

What if inventory reservation fails?

This case is different. The card has already been charged, so the completed payment must be compensated:

PaymentSucceeded
    -> InventoryReservationFailed
    -> RefundRequested
    -> PaymentRefunded
    -> OrderCancelled

PaymentService consumes RefundRequested, processes the refund, and publishes PaymentRefunded. OrderService can then move the order to its final cancelled state.

In a real system, we may use more detailed states such as:

PENDING_PAYMENT
PAYMENT_COMPLETED
AWAITING_INVENTORY
CANCELLATION_PENDING_REFUND
CANCELLED
CONFIRMED

These states make temporary conditions visible and easier to operate safely.

Advantages of choreography

Services remain loosely coupled.
There is no central workflow controller.
Adding an event consumer does not always require modifying the producer.
The approach fits event-driven systems naturally.

Challenges of choreography

The full workflow becomes difficult to see as the number of events grows.
Event loops and unexpected dependencies can develop.
Debugging requires good correlation IDs and distributed tracing.
Compensation logic may be spread across several services.

Choreography works well for relatively simple flows. As a business process becomes more complicated, orchestration can make the workflow easier to understand.

Saga orchestration

In orchestration, a dedicated orchestrator controls the sequence. It sends commands to services, receives their results, and decides which step or compensation should happen next.

A simplified order Saga could look like this:

OrderSagaOrchestrator:
    create pending order
    request payment
    if payment fails:
        cancel order
        stop
    request inventory reservation
    if inventory reservation fails:
        request payment refund
        cancel order
        stop
    confirm order

The orchestrator does not need to contain the internal business logic for charging a card or reserving a product. Those responsibilities still belong to PaymentService and InventoryService. The orchestrator owns the workflow and its state transitions.

Is a Saga orchestrator the same as a 2PC coordinator?

No. They both coordinate participants, but they provide different guarantees.

This distinction helped me understand why Saga orchestration is not simply another implementation of 2PC.

The database-and-Kafka consistency problem

Saga introduces another challenge. A service often needs to save data in its database and publish an event to Kafka.

Consider PaymentService:

Charge the customer.
Save the successful payment.
Publish PaymentSucceeded to Kafka.

What happens if the payment is saved, but the application crashes before step three?

The PaymentService database says the payment succeeded, but InventoryService never receives PaymentSucceeded. The order becomes stuck.

Changing the order of the operations does not solve the problem. If we publish the event first and the database save then fails, other services will react to an event that does not match PaymentService’s state.

Kafka and the service database normally cannot share one local database transaction. This is the dual-write problem.

Simple State Management in React(TypeScript) with Zustand

Md Mahadi Hasan — Wed, 16 Jul 2025 20:46:35 +0000

Zustand is a fast, scalable, and minimal state management library for React. It’s simpler than Redux and works well with small to medium-sized applications. It provides a clean and straightforward API also does not requires any boilerplate to implememt Zustand. It can be used both inside and outside of React components.

There are some advantage on Zustand over redux.

A minimal API with no boilerplate
Global store without the need for React Context
First-class TypeScript support
Middleware support

Step-by-Step: Using Zustand in a React App

1. Install Zustand

Install Zustand with npm or yarn:

npm install zustand
or
yarn add zustand

2. Create a Typed Store

Let’s create a simple counter store with TypeScript types.

// src/store/useCounterStore.ts
import { create } from 'zustand';

interface CounterState {
  count: number;
  increase: () => void;
  decrease: () => void;
  reset: () => void;
}

const useCounterStore = create<CounterState>((set) => ({
  count: 0,
  increase: () => set((state) => ({ count: state.count + 1 })),
  decrease: () => set((state) => ({ count: state.count - 1 })),
  reset: () => set({ count: 0 }),
}));

export default useCounterStore;

3. Use the Store in a Component

Now, let’s use this store inside a React component.

// src/components/Counter.tsx
import React from 'react';
import useCounterStore from '../store/useCounterStore';

const Counter: React.FC = () => {
  const { count, increase, decrease, reset } = useCounterStore();

  return (
    <div style={{ textAlign: 'center' }}>
      <h2>Count: {count}</h2>
      <button onClick={increase}>+</button>
      <button onClick={decrease}>-</button>
      <button onClick={reset}>Reset</button>
    </div>
  );
};

export default Counter;

4. Add the Component to Your App
Use the counter component in your main App.tsx file:

// src/App.tsx
import React from 'react';
import Counter from './components/Counter';

const App: React.FC = () => {
  return (
    <div>
      <h1>Zustand + TypeScript Example</h1>
      <Counter />
    </div>
  );
};

export default App;

Persist State with Middleware
You can persist store values to localStorage using zustand/middleware.

// src/store/useAuthStore.ts
import { create } from 'zustand';
import { persist } from 'zustand/middleware';

interface AuthState {
  token: string | null;
  setToken: (token: string) => void;
  logout: () => void;
}

const useAuthStore = create<AuthState>()(
  persist(
    (set) => ({
      token: null,
      setToken: (token) => set({ token }),
      logout: () => set({ token: null }),
    }),
    {
      name: 'auth-storage', // key in localStorage
    }
  )
);

export default useAuthStore;

Zustand is a powerful and minimal solution for managing global state in React till now. With the support of TypeScript it likes out of the box and it’s ideal for modern applications where simplicity, scalability, and strong typing are needed.

DEV Community: Md Mahadi Hasan