Modern flight booking and payment systems are composed of numerous steps spanning multiple services. For example, an airline booking might involve one service to reserve a seat, another to process payment, and a third to issue the ticket (confirm the seat). All these steps must succeed to complete the booking; if any step fails, the prior steps’ effects should be undone to avoid inconsistencies. In a monolithic system, a single ACID transaction might handle this. But in a distributed microservices architecture, no single transaction can easily encompass seat inventory and payment across systems. As one article notes, in a flight booking scenario, a seat-reservation microservice cannot acquire a lock on the payment database (often an external service), so a different approach to transaction management is required – one that embraces loose coupling and eventual consistency . This is where state machines and the saga pattern come into play.
A state machine models a process as a series of discrete states and transitions in response to events. We can define states corresponding to each stage of booking (seat selection, fare held, payment processing, ticket issued, etc.) and transitions triggered by events like “payment successful” or “seat hold expired.” For example, a travel booking flow might have states such as Booking Flight, Booking Hotel, Booking Car, Confirmation, and Error. Events then drive transitions between these states: e.g. a Flight booked event moves from Booking Flight to the next state, whereas a Flight booking failed event transitions to an Error state. Time-based events like Fare hold timeout are also part of the model . By enumerating all success and failure events (including timeouts), engineers can explicitly capture how the system should react at each step, ensuring no outcome is overlooked.