Designing a Scalable Order State Machine for Complex Transaction Systems

The order state flow is a core component of transaction systems, often involving numerous states, long processing chains, and multiple business dimensions such as different order types, scenarios, and scenes. Maintaining stability while ensuring extensibility and maintainability requires a systematic approach.

Vertical Isolation and Process Orchestration

To separate business logic for each state, the design adopts the State (or Strategy) pattern. A common StateProcessor interface defines an action method, and each concrete state implements this interface. The template method in AbstractStateProcessor orchestrates the six phases: prepare → check → getNextState → action → save → after.

public interface StateProcessor<T, C> {
    ServiceResult<T> action(StateContext<C> context) throws Exception;
}

Validators are abstracted into Checker objects. Serial and parallel execution of parameter, synchronous, and asynchronous checkers are handled by CheckerExecutor, allowing fine‑grained validation while keeping the core flow clean.

public interface Checker<T, C> {
    ServiceResult<T> check(StateContext<C> context);
    default int order() { return 0; }
    default boolean needRelease() { return false; }
    default void release(StateContext<C> context, ServiceResult<T> result) {}
}

Horizontal Logic Reuse and Extension

Beyond vertical isolation, the framework supports plug‑in extensions. Plugins are annotated with @ProcessorPlugin and can be executed between the action and save phases, enabling reusable business steps such as price estimation or promotion handling without modifying the core processors.

@ProcessorPlugin(state = OrderStateEnum.INIT, event = OrderEventEnum.CREATE, bizCode = "BUSINESS")
public class EstimatePricePlugin implements PluginHandler<String, CreateOrderContext> {
    @Override
    public ServiceResult action(StateContext<CreateOrderContext> context) throws Exception {
        String price = ""; // call price service
        context.getContext().setEstimatePriceInfo(price);
        return new ServiceResult();
    }
}

Engine Initialization and Runtime

During Spring startup, all beans annotated with @OrderProcessor are registered in a three‑level map keyed by state, event, and a composite of bizCode and sceneId. At runtime, the OrderFsmEngine builds a StateContext, retrieves the appropriate processor, and executes the template method.

public ServiceResult<T> sendEvent(OrderStateEvent event, FsmOrder order) throws Exception {
    StateContext<?> ctx = new StateContext(event, order);
    StateProcessor<T, ?> processor = getStateProcessor(ctx);
    return processor.action(ctx);
}

Concurrency is handled by a distributed lock (e.g., Redis) around the engine entry point and optimistic locking on the order state in the database, ensuring only one state transition proceeds at a time.

Consistency Between Database and Messaging

The article discusses several strategies to keep order state updates and event messages consistent, including two‑phase commit with RocketMQ, transactional outbox tables, and periodic reconciliation.

Overall, the design combines classic design patterns, template methods, validator composition, and plug‑in architecture to provide a maintainable, extensible, and reliable order state machine suitable for high‑throughput transaction systems.