Design, Migration, and Optimization of Snowball's Self‑Built Fund Trading System

Snowball launched its fund trading service in early 2016 with an independent app called Danjuan Fund, initially offering white‑box strategies and supporting over 4,000 funds across various categories.

The fund trading system evolved from a third‑party solution to a fully self‑built backend over two years, undergoing multiple refactorings and upgrades while remaining transparent to users.

Business Overview

Fund trading mirrors e‑commerce: funds are sellable products, and users must authenticate, bind cards, and pay. The system has two core flows—business flow (order creation, buy/sell actions) and capital flow (fund settlement and transfer). These flows are independent yet interlinked.

The typical purchase flow is:

User initiates a purchase on day T; Danjuan deducts the amount via a third‑party payment.

On T+1, the fund company confirms the purchase and allocates shares.

The corresponding capital flow is:

On T, the user pays; on T+1, the payment institution transfers the money to Danjuan's custodial bank.

The custodial bank then transfers the funds to the fund company.

The custodial bank is responsible for supervising the capital.

Transaction System 1.0

Initially, Danjuan relied on a third‑party fund trading system accessed via APIs and direct database calls, which acted as a black box.

Key problems included:

Core system was uncontrollable, posing high risk.

Daily issue resolution required third‑party involvement, leading to low efficiency.

Upgrades demanded database changes and downtime, which is unacceptable for an internet service.

New feature development was slow due to dependency on the third party.

Consequently, Danjuan decided to develop its own trading system.

Transaction System 2.0

The new system faced two questions: feasibility and user migration. The ecosystem depends on many external services (payment providers, custodial banks, TA), most lacking test environments, making a full‑scale cut‑over impractical.

Danjuan adopted a "production testing, incremental migration" strategy: launch the new system in production with a single test user, gradually add functionality, and migrate users one by one.

Key advantages of this approach:

Problem scope is controllable; early issues affect only a few users.

Test cases can be constructed using the live environment, improving realism.

Two critical technical challenges were solved:

Routing users to the appropriate system based on UID.

Maintaining a single external view despite two internal systems, achieved via a file‑exchange proxy that merges and splits external files.

System modifications included:

UID‑based routing to direct users to the correct backend.

A proxy layer for handling external file exchanges.

Database‑level synchronization for management and configuration data.

After ten months, Danjuan built a self‑owned trading system and completed seamless user migration without user awareness.

Key migration practices:

Start with routing, file proxy, and core purchase/redemption scenarios; test in production with a single user.

Delay migration for users with in‑flight transactions until all intermediate data is cleared.

Allow new feature development in parallel with migration, using feature toggles on the app side.

The final core trading module includes automated fund file imports, business logic processing, dynamic payment routing, and extensive reconciliation abstraction.

Benefits over the previous third‑party system:

New features can be released instantly without downtime.

High degree of automation for file handling and business logic.

Dynamic routing of payment channels.

Model‑driven reconciliation reduces repetitive work.

Payment Channel Optimization

Danjuan integrated multiple third‑party payment providers, each supporting different banks, limits, and fees. The new system enables dynamic configuration of payment channels, combining manual recommendations with automatic fallback rules (e.g., selecting the cheapest combined fee).

Conclusion

Early production launch with incremental user migration proved to be the safest and most effective strategy, exposing risks early while keeping issues manageable. Reducing reliance on uncontrollable third‑party components is essential; when inevitable, start the migration as soon as possible.

Snowball is currently hiring Java engineers, DevOps engineers, test developers, and algorithm engineers; interested candidates can refer to the original posting for details.