Evolution of ZhaiZhai Transaction System: From Monolithic Design to FSM‑Based Modular Architecture
This article chronicles the rapid growth of ZhaiZhai's second‑hand trading platform and explains how its transaction core was refactored from a single‑service monolith into a unified, configurable, FSM‑driven architecture that isolates business lines, abstracts common logic, and improves scalability and maintainability.
The ZhaiZhai platform started as a simple C2C second‑hand marketplace with a monolithic transaction service handling order and refund flows; rapid product expansion introduced B‑to‑B merchants, self‑operated services, and quality‑inspection processes, making the transaction system increasingly complex.
Adopting a middle‑platform model, the transaction layer now provides generic capabilities while business teams build higher‑level features, requiring the system to support multiple concurrent business lines.
In the "Stone Age" stage, each new business scenario was hard‑coded with numerous if‑else branches, leading to high maintenance cost, parallel changes causing regressions, and duplicated code for logging, exception handling, and metrics.
The redesign introduced a unified control model: all order operations share a single OrderContext model, a unified handler selects the appropriate transaction chain, and static/dynamic rule checks precede the final state‑change handler.
Key achievements include a single model governing all order actions, business‑line chain isolation (e.g., phone inspection, C2C, one‑yuan purchase), and logical decomposition into static rules, dynamic rules, handlers, and UI rendering components.
The FSM (Finite State Machine) engine was added as a generic state‑flow solution, supporting offline tasks and reliable distributed messaging. Plugins such as delayed tasks and transaction‑message ensure timely reminders, automatic order closure, and consistent cross‑service updates.
An extensible execution chain allows horizontal composition of processes and vertical assembly of reusable processors, dramatically reducing code duplication.
The Aspect Mechanism acts as a barrier between the transaction core and third‑party systems, shielding platform‑specific attributes while exposing generic capabilities, enabling business teams to plug in custom flows without modifying the core.
Real‑world cases, such as the "early phone inspection" feature, demonstrate how the aspect mechanism lets business teams adjust workflows in a day, while the core remains untouched.
Future work proposes a "scenario mapping" layer above the transaction chain to further decouple business‑specific behavior, improve traceability, and lower integration effort.
Overall, the evolution reflects a continuous push toward configurability, modularity, and scalability to support ZhaiZhai's fast‑growing product landscape.
Zhuanzhuan Tech
A platform for Zhuanzhuan R&D and industry peers to learn and exchange technology, regularly sharing frontline experience and cutting‑edge topics. We welcome practical discussions and sharing; contact waterystone with any questions.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.