Saga pattern for distributed transactions in RabbitMQ - Step-by-Step Execution

Process Flow - Saga pattern for distributed transactions

Start Transaction

↓

Execute Step 1

↓

Publish Event 1

↓

Execute Step 2

↓

Publish Event 2

↓

Check Success?

No→Execute Compensating Step 1

↓

Publish Compensate 1

↓

Execute Step 3

↓

Publish Event 3

↓

End Transaction

The saga pattern breaks a big transaction into steps. Each step publishes an event. If a step fails, compensating steps undo previous work.

Execution Sample

RabbitMQ

Step 1: Reserve inventory
Publish: inventory_reserved
Step 2: Charge payment
Publish: payment_charged
Step 3: Confirm order
Publish: order_confirmed

This sequence shows a saga with three steps, each publishing an event to RabbitMQ to trigger the next step.

Process Table

Step	Action	Event Published	Next Step Triggered	Compensation Triggered
1	Reserve inventory	inventory_reserved	Step 2: Charge payment	No
2	Charge payment	payment_charged	Step 3: Confirm order	No
3	Confirm order	order_confirmed	Transaction complete	No
Error at Step 2	Charge payment fails	payment_failed	No	Step 1: Release inventory

💡 Transaction ends after Step 3 success or after compensation if failure occurs

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Compensation
Inventory Reserved	False	True	True	True	False
Payment Charged	False	False	False	True	False
Order Confirmed	False	False	False	True	False

Key Moments - 2 Insights

Why do we need compensating steps in the saga pattern?

Because each step is independent, if a later step fails, compensating steps undo previous successful steps to keep data consistent, as shown in the error row of the execution table.

How does RabbitMQ help in the saga pattern?

RabbitMQ passes events between steps, triggering the next step or compensation, as seen in the 'Event Published' and 'Next Step Triggered' columns.

Visual Quiz - 3 Questions

Look at the execution table, what event is published after successfully reserving inventory?

A payment_charged

B inventory_reserved

C order_confirmed

D payment_failed

💡 Hint

Check the 'Event Published' column at Step 1 in the execution table.

At which step does the saga pattern trigger compensation if a failure occurs?

A After Step 1

B After Step 3

C At Step 2 failure

D No compensation is triggered

💡 Hint

Look at the 'Compensation Triggered' column in the error row of the execution table.

If the payment step succeeds, what is the state of 'Payment Charged' after Step 3?

A False

B True

C Unknown

D Reverted

💡 Hint

Refer to the variable_tracker row for 'Payment Charged' after Step 3.

Concept Snapshot

Saga pattern breaks a big transaction into steps.
Each step publishes an event to RabbitMQ.
Next step triggers on event reception.
If a step fails, compensating steps undo prior steps.
This keeps distributed data consistent without locking.

Full Transcript

The saga pattern manages distributed transactions by splitting them into smaller steps. Each step performs an action and publishes an event to RabbitMQ. The next step listens for this event and runs. If any step fails, compensating steps run to undo previous successful steps, ensuring data consistency. This pattern avoids locking resources across services. The execution table shows the flow: Step 1 reserves inventory and publishes 'inventory_reserved'. Step 2 charges payment and publishes 'payment_charged'. Step 3 confirms the order and publishes 'order_confirmed'. If Step 2 fails, a compensation step releases the reserved inventory. Variables track the state of each step's success. RabbitMQ acts as the message broker passing events between steps.

Practice

1. What is the main purpose of the Saga pattern in distributed systems using RabbitMQ?

easy

A. To encrypt messages for security

B. To break a large transaction into smaller, manageable local transactions

C. To store messages permanently in RabbitMQ

D. To speed up message delivery between services

Solution

1. Step 1: Understand the Saga pattern concept

   The Saga pattern divides a big transaction into smaller local transactions that can be managed independently.

2. Step 2: Connect to RabbitMQ role

   RabbitMQ helps by passing commands and events between services to coordinate these smaller transactions.

3. Final Answer:

   To break a large transaction into smaller, manageable local transactions -> Option B

4. Quick Check:

   Saga pattern = breaking big transactions [OK]

Hint: Saga splits big tasks into small steps [OK]

Common Mistakes:

• Confusing message speed with transaction management
• Thinking RabbitMQ stores data permanently
• Assuming Saga encrypts messages

2. Which RabbitMQ feature is essential for implementing the Saga pattern?

easy

A. Built-in encryption of messages

B. Direct database access from RabbitMQ

C. Automatic transaction rollback by RabbitMQ

D. Queues to pass commands and events between services

Solution

1. Step 1: Identify RabbitMQ's role in Saga

   RabbitMQ uses queues to send commands and events between services coordinating the Saga steps.

2. Step 2: Eliminate incorrect options

   RabbitMQ does not provide direct database access, automatic rollback, or built-in encryption for Saga.

3. Final Answer:

   Queues to pass commands and events between services -> Option D

4. Quick Check:

   RabbitMQ queues = Saga communication [OK]

Hint: Saga needs queues to connect services [OK]

Common Mistakes:

• Thinking RabbitMQ manages database transactions
• Assuming RabbitMQ rolls back transactions automatically
• Confusing message encryption with Saga logic

3. Consider a Saga with three steps: A, B, and C. Step B fails after A succeeds. What happens next in a RabbitMQ-based Saga?

medium

A. The entire Saga commits successfully

B. Step C executes anyway

C. Compensating transaction for step A is triggered

D. RabbitMQ automatically retries step B indefinitely

Solution

1. Step 1: Understand failure handling in Saga

   If step B fails, the Saga triggers compensating transactions to undo previous successful steps.

2. Step 2: Apply to given steps

   Since A succeeded before B failed, a compensating transaction for A is triggered to rollback its effects.

3. Final Answer:

   Compensating transaction for step A is triggered -> Option C

4. Quick Check:

   Failure triggers compensations, not commits [OK]

Hint: Failed step triggers undo of prior steps [OK]

Common Mistakes:

• Assuming next steps run despite failure
• Thinking Saga commits on failure
• Believing RabbitMQ retries endlessly without control

4. You implemented a Saga using RabbitMQ but noticed that compensating transactions are not triggered on failure. What is the most likely cause?

medium

A. The failure event is not published to the queue

B. RabbitMQ queues are overloaded

C. The database is down

D. Messages are encrypted

Solution

1. Step 1: Identify failure handling in Saga

   Compensating transactions rely on failure events being published and consumed to trigger rollback.

2. Step 2: Analyze the problem

   If compensations are not triggered, likely the failure event was not sent to the RabbitMQ queue for processing.

3. Final Answer:

   The failure event is not published to the queue -> Option A

4. Quick Check:

   Missing failure event = no compensation [OK]

Hint: Check if failure event reaches queue [OK]

Common Mistakes:

• Blaming queue overload without checking events
• Assuming database issues cause compensation skip
• Confusing encryption with event delivery

5. You design a distributed order processing system using RabbitMQ and the Saga pattern. Which approach best ensures data consistency across services when one service fails mid-transaction?

hard

A. Use compensating transactions triggered by failure events sent via RabbitMQ queues

B. Rely on RabbitMQ to automatically rollback all previous steps

C. Commit all local transactions immediately without rollback

D. Use a single global database transaction across all services

Solution

1. Step 1: Understand distributed transaction challenges

   Global transactions are hard across services; Saga uses local transactions with compensations.

2. Step 2: Apply RabbitMQ and Saga pattern

   Failure events sent via RabbitMQ trigger compensating transactions to undo previous steps, ensuring consistency.

3. Step 3: Eliminate incorrect options

   RabbitMQ does not rollback automatically; immediate commits without rollback risk inconsistency; global DB transactions are not feasible across services.

4. Final Answer:

   Use compensating transactions triggered by failure events sent via RabbitMQ queues -> Option A

5. Quick Check:

   Compensations + RabbitMQ events = consistency [OK]

Hint: Compensate on failure via RabbitMQ events [OK]

Common Mistakes:

• Expecting RabbitMQ to rollback automatically
• Ignoring rollback leads to inconsistent data
• Trying global DB transactions across microservices