---
title: "Travel Booking Saga and Compensation Patterns"
description: "Design Saga and compensation patterns for travel booking, payment, cancellation and refund workflows where rollback is impossible."
slug: "travel-booking-saga-compensation-patterns"
translationKey: "architecture-travel-booking-saga-compensation-patterns"
locale: "en"
type: "guide"
category: "architecture"
tags: ["saga","compensation","booking","payment","distributed-systems"]
publishedAt: "2026-09-27"
updatedAt: "2026-09-27"
reviewedAt: "2026-09-27"
technicalVerifiedAt: "2026-09-27"
codeExampleStatus: "illustrative"
---

A travel booking distributed transaction cannot be rolled back atomically. Supplier booking, payment capture, ticketing and refund occur in separate systems, so failures require **compensating actions**.

## Saga flow

```mermaid
%% title: Travel booking Saga
%% description: Payment and booking steps use forward recovery or compensation after failures.
flowchart TD
  A[Authorize Payment] --> B[Create Booking]
  B -->|failed| C[Void Authorization]
  B -->|confirmed| D[Capture Payment]
  D -->|captured| E[Complete]
  D -->|failed| F[Payment Recovery]
  F -->|recoverable| D
  F -->|not recoverable| G[Cancel Booking]
  G --> H[Void / Refund]
```

## Compensation is not rollback

Booking cancellation can incur fees, return different inventory conditions or complete asynchronously. Refund can be delayed by settlement, create FX differences or leave non-refundable payment costs. Compensation therefore needs its own tracked outcome.

## Orchestration vs choreography

### Orchestration

A central Saga orchestrator knows the next step. This improves debugging, explicit state and operational visibility, at the cost of a more complex orchestrator.

### Choreography

Services react to events. Coupling is looser, but the global flow is harder to reason about and duplicate/out-of-order events can have wider consequences.

For financially critical travel workflows, explicit orchestration is often easier to operate.

## Saga step model

Persist operation, status, forward action, compensation action, idempotency key, attempt count, last evidence and next retry time for every step.

## Forward recovery or compensation?

When capture fails, do not automatically cancel the booking. First decide whether capture can be retried safely, another payment path exists, traveler liability is preserved, cancellation fees apply, or manual operations are safer.

## Compensation matrix

| Forward step | Failure | Compensation |
|---|---|---|
| authorize | booking failed | void |
| capture | booking later cancelled | refund/void |
| booking confirmed | payment unrecoverable | cancel booking |
| ticket issued | servicing failed | provider-specific servicing |
| cancellation confirmed | refund failed | refund reconciliation |

## UNKNOWN compensation

Do not blindly compensate while the original outcome is UNKNOWN. Gather authoritative evidence first; otherwise compensation may itself create an incorrect state.

## Failure modes

Duplicate compensation, compensation UNKNOWN outcome, ignored cancellation fees, compensating too early, choreography event loops and marking partially compensated flows as completed.

## Observability

Track Saga completion, compensation rate and outcome, forward-recovery rate, manual interventions, time in RECOVERY_REQUIRED and financial cost of compensation.

## Production checklist

Use explicit Saga state, idempotent forward and compensation actions, provider-specific compensation policy, UNKNOWN-safe recovery, financial-impact visibility, manual escalation, audit trails and replay-safe event handling.