Backend interview prep

Start

Distributed Transactions Interview Questions and Answers

Learn Distributed Transactions with interview questions, Mermaid diagrams, Spring Boot examples, Two-Phase Commit (2PC), Saga Pattern, Outbox Pattern, Kafka, and enterprise production best practices.

Distributed Transactions - Interview Questions & Answers

In a monolithic application, maintaining data consistency is straightforward because all operations occur within a single database transaction.

In a microservices architecture, however, each service owns its own database.

For example:

  • Order Service → Order Database
  • Payment Service → Payment Database
  • Inventory Service → Inventory Database
  • Shipping Service → Shipping Database

Now imagine placing an order.

If payment succeeds but inventory reservation fails, how do we maintain consistency?

This problem is solved using Distributed Transactions.

Distributed transactions are one of the most important topics in System Design, Kafka, Spring Boot, and Solution Architect interviews.

Distributed Transaction Architecture

flowchart LR

Client --> OrderService["Order Service"]

OrderService["Order Service"] --> OrderDb["Order DB"]

OrderService["Order Service"] --> Kafka

Kafka --> PaymentService["Payment Service"]

PaymentService["Payment Service"] --> PaymentDb["Payment DB"]

Kafka --> InventoryService["Inventory Service"]

InventoryService["Inventory Service"] --> InventoryDb["Inventory DB"]

Kafka --> ShippingService["Shipping Service"]

ShippingService["Shipping Service"] --> ShippingDb["Shipping DB"]

Q1. What is a Distributed Transaction?

Answer

A Distributed Transaction is a transaction that spans multiple independent services or databases.

Unlike a traditional ACID transaction, each service performs its own local transaction.

The overall business transaction succeeds only if all participating services complete successfully.

Example

Create Order

↓

Process Payment

↓

Reserve Inventory

↓

Create Shipment

Workflow

flowchart TD

Order --> Payment

Payment --> Inventory

Inventory --> Shipping

Q2. Why are Distributed Transactions difficult?

Answer

Each microservice owns its own database.

No single database transaction can span:

  • MySQL
  • PostgreSQL
  • Oracle
  • MongoDB

Failures can occur at any step.

Examples:

  • Payment timeout
  • Database crash
  • Network failure
  • Service unavailable

Failure Example

flowchart LR

OrderSuccess["Order Success"] --> PaymentSuccess["Payment Success"]

PaymentSuccess["Payment Success"] --> InventoryFailure["Inventory Failure"]

InventoryFailure["Inventory Failure"] --> InconsistentState["Inconsistent State"]

Interview Tip

Distributed systems prioritize availability over strict ACID transactions.

Q3. What are the approaches for Distributed Transactions?

Answer

The two major approaches are:

Two-Phase Commit (2PC)

Coordinator controls all participants.

Saga Pattern

Each service executes a local transaction.

Failures are handled using compensation.

Overview

mindmap
  root((Distributed Transactions))
    Two Phase Commit
    Saga Pattern

Q4. What is Two-Phase Commit (2PC)?

Answer

Two-Phase Commit is a protocol that coordinates multiple databases.

It consists of two phases.

Phase 1

Prepare

All participants vote.

Phase 2

Commit or Rollback

Coordinator decides based on votes.

2PC Flow

sequenceDiagram
participant Coordinator
participant DB1
participant DB2
Coordinator->>DB1: Prepare
Coordinator->>DB2: Prepare
DB1-->>Coordinator: Yes
DB2-->>Coordinator: Yes
Coordinator->>DB1: Commit
Coordinator->>DB2: Commit

Benefits

  • Strong consistency

Challenges

  • Blocking
  • Coordinator failure
  • Poor scalability

Q5. What is the Saga Pattern?

Answer

Saga replaces one global transaction with multiple local transactions.

Each successful step publishes an event.

If a later step fails, compensation transactions undo previous work.

Saga Workflow

flowchart LR

Order --> Payment

Payment --> Inventory

Inventory --> Shipping

Compensation

flowchart LR

Payment --> InventoryFailure["Inventory Failure"]

InventoryFailure["Inventory Failure"] --> RefundPayment["Refund Payment"]

Best Practice

Saga is the preferred approach for cloud-native microservices.

Q6. How does the Outbox Pattern help?

Answer

Distributed transactions often require reliable event publishing.

The Outbox Pattern stores:

  • Business Data
  • Event

inside one database transaction.

Later, CDC publishes the event to Kafka.

Outbox

flowchart TD

BusinessTransaction["Business Transaction"] --> BusinessTable["Business Table"]

BusinessTransaction["Business Transaction"] --> OutboxTable["Outbox Table"]

OutboxTable["Outbox Table"] --> Debezium

Debezium --> Kafka

Benefits

  • Eliminates Dual Write Problem
  • Reliable event publishing

Q7. How does Spring Boot implement Distributed Transactions?

Answer

Spring Boot commonly uses:

  • Spring Boot
  • Spring Kafka
  • Outbox Pattern
  • Saga Pattern
  • Kafka
  • REST APIs

Typical workflow:

REST API

↓

Order Service

↓

Outbox

↓

Kafka

↓

Payment

↓

Inventory

↓

Shipping

Spring Boot Architecture

flowchart TD

RestApi["REST API"] --> OrderService["Order Service"]

OrderService["Order Service"] --> Outbox

Outbox --> Kafka

Kafka --> Payment

Kafka --> Inventory

Kafka --> Shipping

Q8. What are common implementation mistakes?

Answer

Common mistakes include:

  • Using 2PC everywhere
  • No compensation logic
  • Ignoring duplicate events
  • No retries
  • No DLQ
  • No idempotency
  • Tight coupling

Wrong Design

Global Transaction

↓

Every Microservice ❌

Correct Design

Local Transaction

↓

Event

↓

Saga

↓

Compensation ✅

Q9. What are the advantages and challenges?

Answer

Advantages

  • Independent databases
  • Better scalability
  • High availability
  • Loose coupling
  • Cloud native

Challenges

  • Eventual consistency
  • Compensation logic
  • Monitoring
  • Duplicate handling
  • Recovery

Pros & Cons

mindmap
  root((Distributed Transactions))
    Advantages
      Scalability
      Independence
      Availability
    Challenges
      Compensation
      Complexity
      Monitoring

Q10. What are the enterprise best practices?

Answer

Follow these recommendations:

  • Prefer Saga over 2PC for microservices.
  • Keep local transactions small.
  • Use the Outbox Pattern.
  • Build idempotent consumers.
  • Configure retries and DLQs.
  • Use correlation IDs.
  • Monitor transaction flow.
  • Implement replay capabilities.
  • Test compensation scenarios.
  • Design for eventual consistency.

Enterprise Architecture

flowchart TD

Client --> OrderService["Order Service"]

OrderService["Order Service"] --> OrderDb["Order DB"]

OrderService["Order Service"] --> Outbox

Outbox --> Kafka

Kafka --> PaymentService["Payment Service"]

PaymentService["Payment Service"] --> PaymentDb["Payment DB"]

Kafka --> InventoryService["Inventory Service"]

InventoryService["Inventory Service"] --> InventoryDb["Inventory DB"]

Kafka --> ShippingService["Shipping Service"]

ShippingService["Shipping Service"] --> ShippingDb["Shipping DB"]

Transaction Flow

flowchart LR

Command --> LocalTransaction["Local Transaction"]

LocalTransaction["Local Transaction"] --> Event

Event --> NextService["Next Service"]

NextService["Next Service"] --> CompensationIfNeeded["Compensation if Needed"]

Distributed Transactions Overview

mindmap
  root((Distributed Transactions))
    2PC
    Saga
    Outbox
    Kafka
    Compensation
    Retry
    DLQ
    Monitoring

Two-Phase Commit vs Saga

Feature Two-Phase Commit Saga Pattern
Coordinator Required Optional
Database Locking Yes No
Scalability Low High
Availability Lower Higher
Cloud Native Poor Excellent
Compensation No Yes
Enterprise Adoption Limited Very High

Real-World Banking Example

A customer transfers ₹1,00,000.

Successful Flow

Transfer Request

↓

Debit Account

↓

Credit Account

↓

Notification

↓

Audit Log

Failure Flow

Debit Completed

↓

Credit Failed

↓

Compensation

↓

Reverse Debit

↓

Notify Customer

The customer balance remains consistent even though multiple services participate.

Senior Interview Tip

Modern enterprises rarely use Two-Phase Commit for large-scale microservices because of scalability and availability concerns.

Instead, production architectures commonly use:

  • Spring Boot
  • Apache Kafka
  • Saga Pattern
  • Outbox Pattern
  • Debezium CDC
  • Dead Letter Queue
  • Retry Topics
  • Idempotent Consumers
  • Correlation IDs
  • Event Versioning
  • Prometheus & Grafana
  • OpenTelemetry
  • Audit Logging
  • Replay Services

Remember:

  • 2PC provides strong consistency but reduces scalability.
  • Saga provides eventual consistency through compensation.
  • Outbox guarantees reliable event publishing.
  • Idempotency is essential for safe retries and replay.

Quick Revision

  • Distributed Transactions span multiple services and databases.
  • Traditional ACID transactions cannot span independent microservices.
  • Two-Phase Commit provides strong consistency but has scalability limitations.
  • Saga Pattern coordinates local transactions using compensation.
  • Outbox Pattern ensures reliable event publishing.
  • Use idempotent consumers to safely handle retries.
  • Configure retries, DLQs, and replay services.
  • Monitor transaction execution and compensation flows.
  • Prefer eventual consistency for cloud-native architectures.
  • Combine Spring Boot, Kafka, Saga, Outbox, monitoring, and replay for enterprise-grade distributed transaction management.