Design and Implementation of a State Machine for E‑commerce After‑sale Services

1. Background

In the e‑commerce industry, after‑sale services involve extremely complex business scenarios that must interact with order flow, quality inspection, warehousing, and logistics. The core component of the after‑sale process is a state machine that drives the flow of documents.

2. Design and Implementation

2.1 Action Execution Abstraction

For an after‑sale order, the document status reflects processing progress, and status changes are driven by actions. The simplest implementation uses if else statements, which become unmaintainable as the number of states grows. Therefore, actions are abstracted into a template.

Each action can be expressed as a generic expression (illustrated in the original diagram). Using the Strategy pattern, different actions are encapsulated into independent execution units.

An abstract class is introduced between the implementation class and the interface, or default methods can be used directly in the interface to provide basic implementations.

The author defines four common methods: preInvoke (pre‑business validation), invoke (core action logic), postInvoke (post‑processing of additional data), and autoNext (automatic transition to the next specified action). These methods form the skeleton of the state‑machine data flow.

2.2 Synchronous or Asynchronous

The state‑machine guarantees normal flow, but certain steps—especially autoNext —can cause long request times. For example, after a customer‑service approval, the system may need to automatically trigger a logistics operation, turning a single‑step audit into a two‑step process and extending the interface latency.

To avoid blocking the original request, the automatic step is moved to an asynchronous thread, decoupling it from the manual operation. Asynchronous execution improves overall response time, but it raises the question of how to handle failures that occur without user awareness.

2.3 Compensation Mechanism

2.3.1 Technical Choice

Spring provides the @Retryable annotation for retrying failed operations, but the author prefers using a message‑queue (MQ) approach for more flexible and controllable retries, especially when failures are not expected to recover quickly.

2.3.2 Solution Implementation

During processing, any failed action or exception is captured and a delayed MQ message is sent. The message contains the action and its business data; the delay duration can be customized per business requirement. When the delayed message is consumed, the system retries the failed action, achieving a compensation mechanism.

2.4 Execution Delay

Inspired by the compensation mechanism, delayed execution is applied broadly. By leveraging delayed MQ, the system can automatically progress the state machine when no manual handling occurs within a configured time window. For instance, if an after‑sale audit is not manually processed within the delay, the system autonomously triggers the audit step.

3. Summary

The state machine abstracts execution processes, allowing the workflow to be templated and reused across various business scenarios. With this framework in place, developers can address specific pain points—such as long‑running operations, failure compensation, and automatic transitions—by extending and enriching the functionality as needed.