# Exercise 1: Design a Saga for a Travel Booking Platform

## Scenario

You're designing the booking flow for `TripStitch`, a travel platform that lets a customer book a flight, a hotel, and a rental car in one checkout, across three separate downstream services (each owned by a different team, each with its own database):

- **Flight Service** — reserves a seat on a specific flight and charges the fare.
- **Hotel Service** — reserves a room for the given date range and charges for the stay.
- **Car Service** — reserves a rental car for the trip dates and places a hold on a deposit.

A booking is only meaningful if **all three** reservations succeed — a customer who gets a flight and a hotel but no car (because cars were sold out at that location) needs the flight and hotel undone too, not left dangling.

## Deliverables

Produce all of the following, in this file, below this line:

1. **A step-by-step saga sequence** — list each local transaction in the order it runs, which service owns it, and what compensating transaction would undo it. Use the table format: Step | Service | Forward Action | Compensating Action.
2. **A choreography vs orchestration decision, justified** — pick one coordination style for this saga and justify it using the tradeoffs from theory Part 2 Section 3 (readability/debuggability vs decoupling). Explicitly address why the other choice would be worse for a THREE-team-owned saga like this one.
3. **A failure trace** — pick one specific step to fail (you choose which) and write out, in order, exactly which compensating transactions fire, in which order, and what the customer-visible state of the booking looks like at the end. Justify the compensation ORDER using theory Part 2 Section 2's guidance.
4. **The intermediate-state problem, addressed concretely** — theory Part 2 Section 4 explains that a saga is only eventually consistent, so intermediate states are observable. Describe one concrete way a customer or another part of the system (e.g. a "my bookings" page) could observe TripStitch's booking mid-saga, and what status value your design would show them at that moment so it doesn't look broken or contradictory.

## Constraints

- Do not use two-phase commit anywhere in your design — this saga must use only independently-committed local transactions per theory Part 1's guidance on why 2PC is a poor fit here (three separately-owned services/databases).
- Every compensating action must be a plausible real operation (a refund, a cancellation, a hold-release) — no step may claim to be "undoable" via a database rollback, since by the time compensation runs, the original step has already committed.
- The booking record must never be silently deleted on failure — it must end in an explicit terminal status a customer-facing UI could display, per theory Part 2 Section 4.