Reservations Before Actions
TCC (Try-Confirm-Cancel) is a distributed transaction pattern that sits between 2PC and Sagas in terms of its consistency model. It is particularly well-suited for systems that deal in explicit reservations — airline seats, hotel rooms, concert tickets, inventory holds.
The key insight is that TCC separates the act of reserving a resource from the act of consuming it. This avoids the problem of Sagas where a forward action immediately changes real state (and must be compensated later). Instead, TCC holds resources in a "tentative" state until the overall outcome is known.
The Three Phases
1. Try Phase
Each participating service checks whether it can fulfill its part of the request and places a soft reservation on the required resources. No permanent state change occurs yet.
FlightService.try(): Checks seat availability, marks seat as "tentatively held" for 10 minutes.HotelService.try(): Checks room availability, marks room as "tentatively held" for 10 minutes.CarService.try(): Checks car availability, marks car as "tentatively held" for 10 minutes.
If any try() call fails (resource unavailable), the overall transaction is aborted immediately — no compensation needed, because no permanent changes were made.
2. Confirm Phase
If all try() calls succeed, a coordinator calls confirm() on each service. This converts the soft reservation into a real, permanent booking.
FlightService.confirm(): Converts the tentative hold into a confirmed ticket.HotelService.confirm(): Converts the tentative hold into a confirmed booking.CarService.confirm(): Converts the tentative hold into a confirmed reservation.
3. Cancel Phase
If any try() fails, or if the business logic decides not to proceed, the coordinator calls cancel() on all services that successfully completed try(). This releases the soft reservation.
FlightService.cancel(): Releases the tentative seat hold.HotelService.cancel(): Releases the tentative room hold.
TCC vs. Sagas: The Key Difference
| Aspect | Saga | TCC |
|---|---|---|
| Forward action | Immediately commits real state | Reserves tentative state only |
| Failure handling | Compensating transactions (undo real changes) | Cancel phase (release reservations) |
| Intermediate visibility | Real (but incomplete) state is visible | Tentative state is visible (clearly marked as "held") |
| Complexity | Lower — compensations are simpler | Higher — every operation needs Try/Confirm/Cancel logic |
| Best for | General business workflows | Resource reservation systems |
TCC requires more upfront design work — every service must implement all three operations, and reservations must expire automatically (via timeouts) in case the coordinator crashes before calling Confirm or Cancel. But for domains where double-booking is catastrophic, TCC's "reserve first, act second" model is worth the investment.