Saga pattern for distributed transactions in RabbitMQ - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to send a message to start a saga transaction.

RabbitMQ

channel.basic_publish(exchange='saga_exchange', routing_key='start', body=[1])

Drag options to blanks, or click blank then click option'

Astart_saga()

Border_id

C'{"order_id": 123}'

DNone

Attempts:

3 left

💡 Hint

Common Mistakes

Sending a variable name instead of a JSON string

Using None as message body

The message body must be a string or bytes representing the order details in JSON format.

2fill in blank

medium

Complete the code to acknowledge a message after processing in the saga.

RabbitMQ

channel.basic_ack(delivery_tag=[1])

Drag options to blanks, or click blank then click option'

Amethod.delivery_tag

Bbody

Cchannel

Dmessage

Attempts:

3 left

💡 Hint

Common Mistakes

Using the message body instead of delivery tag

Using channel object as delivery tag

The delivery tag from the method frame is used to acknowledge the message.

3fill in blank

hard

Fix the error in the saga compensation step to publish a rollback message.

RabbitMQ

channel.basic_publish(exchange='saga_exchange', routing_key=[1], body=rollback_data)

Drag options to blanks, or click blank then click option'

Arollback_data

Brollback

C'commit'

D'rollback'

Attempts:

3 left

💡 Hint

Common Mistakes

Using variable rollback_data as routing key

Omitting quotes around routing key

The routing key must be a string specifying the rollback action.

4fill in blank

hard

Fill both blanks to declare a durable queue and bind it to the saga exchange.

RabbitMQ

channel.queue_declare(queue=[1], durable=[2])
channel.queue_bind(queue='saga_queue', exchange='saga_exchange', routing_key='start')

Drag options to blanks, or click blank then click option'

A'saga_queue'

BTrue

CFalse

D'start_queue'

Attempts:

3 left

💡 Hint

Common Mistakes

Using incorrect queue name

Setting durable to False causing message loss

The queue name must be a string and durability should be set to True for persistence.

5fill in blank

hard

Fill all three blanks to create a saga step that consumes messages, processes them, and sends a compensation if needed.

RabbitMQ

def on_message(channel, method, properties, body):
    data = json.loads(body)
    if data.get('status') == [1]:
        process(data)
    else:
        channel.basic_publish(exchange='saga_exchange', routing_key=[2], body=json.dumps(data))
    channel.basic_ack(delivery_tag=[3])

Drag options to blanks, or click blank then click option'

A'success'

B'rollback'

Cmethod.delivery_tag

D'fail'

Attempts:

3 left

💡 Hint

Common Mistakes

Using wrong status string

Not acknowledging messages properly

Using incorrect routing key for compensation

The saga step processes messages with status 'success', sends rollback messages on failure, and acknowledges using method.delivery_tag.

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