Transaction Middleware: FSM and Concurrency Model Practices and Exploration

Background

Zhuanzhuan, a leading second‑hand trading platform in China, has evolved since its 2015 launch from a pure C2C model to a multi‑mode ecosystem (B2C, C2B, B2B, C2B2C) covering dozens of categories such as mobile devices, books, games, and luxury goods.

The company adopts a middle‑platform architecture, where the transaction middle platform provides generic, stable trading capabilities and quickly responds to front‑end business needs, while front‑end teams focus on innovative user‑facing services.

Problems Faced by the Transaction Middle Platform

The order system of the middle platform serves all business lines, but each line has a complex and varied transaction flow, leading to differences in main nodes, inventory locking, shipping, settlement, and other steps.

Different business models have distinct main nodes and lock/ship/settle points.

Multiple business models must coexist without affecting each other.

The transaction flow must be extensible, reusable, low‑maintenance, and fast‑responding to support rapid iteration.

Stability, data accuracy, visualizable processes, and quick issue location are required.

Traditional hard‑coded approaches can no longer meet these requirements; a finite‑state‑machine (FSM) solution becomes necessary.

Transaction Flow Practices and Exploration

3.1 FSM (Finite‑State Machine) Practice

What is an FSM?

An FSM (Finite‑State Machine) is a mathematical model that represents a limited set of states and the transitions/actions between them, commonly used to describe an object's lifecycle and its response to external events. Zhuanzhuan’s transaction middle platform leverages this principle to provide a generic state‑flow solution for order processing.

What can the FSM solution do?

The FSM enables rapid construction of any document flow that requires state transitions, while also handling related offline tasks and transactional messages.

The Four Elements of an FSM

An FSM abstracts the transaction flow into four elements: current state (present), event, action, and target state (next). The present state and event are causes; the action and next state are effects.

Present State : The current state.

Event : Also called a “condition”; when it occurs it triggers an action or a state transition.

Action : The operation executed when the condition is satisfied; it may lead to a new state or keep the current one.

Next State : The state to transition to after the condition is satisfied.

FSM Implementation in the Order System

The order system abstracts role‑based state relationships, including:

State relations: initial state, target state.

Roles: seller, buyer, system, customer service, each with different permissions.

Operations: correspond to events.

Handlers: correspond to actions.

Visualizing the FSM Transaction Flow

Operations staff can view a panoramic diagram of the FSM state transitions for a specific transaction flow.

While FSM solves the state‑flow problem for the main transaction chain, it is not suitable for stateless single‑node sub‑chains such as order creation, which involve multi‑dimensional validation and integration.

3.2 Future‑Based Staged Concurrency Model

Order creation is far more complex than a simple INSERT; it involves multiple logical steps:

Information retrieval (product, user, address, inventory, promotions, coupons, business line, tags, etc.)

Validation (stock, address, coupon, product cycle, service, price, points, purchase limits, etc.)

Risk control interception

Order data assembly

Stock locking (virtual, physical, service, coupon, points)

Promotion budget deduction

Persistence (create order, create payment record)

Operation logs, tracing, etc.

These steps illustrate the high complexity of the ordering logic.

a. Traditional Serial Process Model

The traditional serial model cannot meet performance, flexibility, or extensibility requirements, prompting the adoption of a future‑based staged concurrency model.

b. Future‑Based Staged Concurrency Model

Advantages over the traditional model include:

Multi‑threading dramatically improves overall interface performance.

Code is abstracted into functional, Lego‑like blocks, greatly enhancing reusability.

Scalability and maintainability receive a qualitative leap.

Drawbacks:

Concurrency is strictly grouped; the group’s latency is bounded by the longest task.

Thread‑pool utilization may be sub‑optimal within groups.

3.3 Event‑Driven Concurrency Model Exploration

Zhuanzhuan’s Avenger series provides a more efficient concurrency component (Avenger‑Ultron) compared to the staged model.

Currently, this event‑driven model is widely used across the company for complex concurrent scenarios that require aggregating dozens of RPC calls within a single user request.

Transitioning from the traditional serial model to the future‑based staged model represents a 0‑to‑1 leap; moving from the staged model to the event‑driven model is a 1‑to‑100 leap, and with additional tooling (topology graphs, monitoring, circuit‑breakers, degradation), the improvement can be considered 100‑to‑∞.

Conclusion

The concurrency models address stateless, high‑concurrency scenarios (e.g., product list, detail, homepage), while FSM primarily solves state‑flow challenges in complex business transaction chains. FSM’s applicability extends beyond order processing to other stateful workflows such as OA approvals and quality‑inspection pipelines.

FSM is a framework; a complete surrounding business‑logic layer is required to realize its full potential within the transaction middle platform, forming a healthy technical ecosystem.

Author Bio

Guo Shijie, Transaction Middle Platform R&D Engineer at Zhuanzhuan.