Boosting Ticket Order Systems with State Machines: Design & Lessons

Finite State Machine Concept

A finite state machine (FSM) models object behavior by defining a limited set of stable states and the transitions triggered by events, simplifying complex logic into a mathematical model that determines state changes based on current state and input.

Why Use FSM in Ticket Order Systems

Order processing involves multiple dimensions, products, and suppliers, leading to intricate workflows. Without an FSM, handling a payment success callback would require a long chain of if‑else statements, tightly coupling code and making maintenance difficult. An FSM abstracts all states, events, and actions, replacing verbose conditional logic with a clear, maintainable transition model.

State Machine Design

At the database level, a main order represents the overall transaction, while each supplier’s portion is stored as a sub‑order. For example, a single purchase may generate one main order and two sub‑orders (ticket and insurance), each with its own supplier and settlement process.

Two separate FSMs manage the forward (ticket issuance) and reverse (refund/changes) flows. The main‑order FSM handles states such as order created, payment successful, transaction completed, and order closed. The sub‑order FSM tracks the lifecycle from reservation to ticket issuance.

Framework Selection

After comparing popular FSM engines—Spring Statemachine, Stateless4j, and Squirrel‑Foundation—the team chose Squirrel‑Foundation because it offers moderate code size, lightweight instances, rich hook points (state entry, exit, exception), annotation‑based transition definitions, and a clear lifecycle without singleton reuse complications.

MSM Design and Implementation

Building on Squirrel‑Foundation, the team created the MSM (MFW State Machine) framework, extracting an Action concept to encapsulate state transitions and associated asynchronous messages. Each Action class extends AbstractAction and defines matching conditions, context, and processing logic.

Key implementation steps:

Define Action classes with matchConditions() to map initial state‑event pairs.

Register actions and listeners for success or failure.

Integrate RocketMQ by extending BaseMessageSender and BaseMsgTransactionListener for transactional messaging.

Create an event trigger that instantiates the FSM, sets the current state from the database, and calls fire().

Upon firing, the FSM invokes the annotated method in OrderStateMachine, which reflects to execute the corresponding Action.

The Action execution follows a factory pattern to retrieve the appropriate action, runs process(), and triggers either TransitionCompleteListener (updating DB and sending messages) or TransitionExceptionListener (handling failures).

Pitfalls Encountered

Transaction Not Effective: Spring @Transactional annotations failed inside the same class due to AOP proxy limitations; resolved by manually managing transactions.

Action Matching: Shifted from imprecise to precise multi‑condition matching to avoid incorrect action selection.

Asynchronous Message Consistency: Used RocketMQ transactional messages to ensure DB updates and message sends succeed or roll back together.

Concurrent Event Handling: Prevented race conditions on the same order by employing optimistic locking (update with original status check) rather than pessimistic locks.

Conclusion

By defining FSMs on top of Squirrel‑Foundation and encapsulating transition logic in reusable Action classes, the MSM framework simplifies order state management, enhances system stability, scalability, and maintainability, and can be applied to other complex workflow domains.