Try-Confirm-Cancel
also called TCC, Reservation Pattern
A three-phase distributed transaction where each participant first reserves resources, and a coordinator then confirms or cancels all reservations.
A middle point between two-phase commit and a saga. Each service exposes three operations: Try reserves what is needed without committing the business effect (hold the seat, authorise the card, reserve the stock); Confirm makes the reservation real; Cancel releases it.
Its advantage over a plain saga is that the awkward step is moved earlier. In a saga, a late failure means compensating steps that have already taken visible effect — a refund rather than a non-charge. With TCC, nothing is visible until the confirm phase, so cancellation is usually clean.
Its advantage over 2PC is that reservations are application-level, so no database locks are held across the network and no participant is blocked by a coordinator failure; a reservation simply expires.
The costs are real: every participant must implement three idempotent operations rather than one, and reservations need expiry so an abandoned transaction releases resources. It fits domains that already think in reservations — travel, ticketing, inventory, payments — and is heavy machinery for domains that do not.