How RocketMQ Improves Financial Customer‑Accompaniment Efficiency with Transactional Messaging

Industry Background

Boshi Fund, one of the first five fund‑management companies in mainland China, managed 276 public funds with assets of over CNY 1.55 trillion as of June 2021. Its business is split between investment‑research (investment management and industry research) and market‑line activities (fund sales and customer service). With the rise of online channels, the customer base became large and heterogeneous, requiring a guided “accompaniment” approach to help investors understand risks and products.

RocketMQ in the Accompaniment System

1. Accompaniment scenario overview

The fund built a multi‑layered accompaniment platform that delivers pre‑investment, during‑investment and post‑investment services across user, market and product dimensions. Realising these services requires coordination among research, compliance, operations, and big‑data platforms. Synchronous calls would create tight coupling and hinder future expansion.

2. Decoupling heterogeneous systems with RocketMQ

RocketMQ provides high‑performance, reliable publish‑subscribe messaging. By replacing file‑ and email‑based hand‑offs with an online, workflow‑driven message flow, the system reduced latency and increased throughput. Topics and Tags are used to classify messages, enabling fine‑grained filtering and indexing.

3. Topic and Tag best practices

Topic Accompaniment – first‑level category for all accompaniment‑related events.

Tag Ops – messages consumed by the operations subsystem.

Tag CS – messages consumed by the customer‑service subsystem.

Tag Orchestration – messages consumed by the orchestration engine.

Compliance subsystem subscribes to Tags Ops and Orchestration for audit checks.

Data‑center subsystem listens to all Tags for centralized processing.

RocketMQ Transactional Messages in Financial Scenarios

1. Financial scenario overview – “Discount Purchase”

The Discount Purchase feature allows an investor to buy a target fund with a zero‑fee rate by first loading a Boshi Wallet and then purchasing the fund. The original implementation required two separate steps (wallet recharge + fund purchase), causing user drop‑off. Transactional messaging merges the two steps into a single atomic operation, simplifying the user flow.

2. Domain‑event model

Domain events represent a business step that triggers downstream actions (e.g., login, fund purchase). The model adopts eventual consistency, allowing microservices to remain loosely coupled. Two patterns are distinguished:

Same‑service event: The event occurs within a single process; a local transaction suffices, but if multiple aggregates must be updated, an internal event bus is introduced.

Cross‑service event: The event spans multiple services; a global transaction coordinator is required. The solution hinges on event creation, publishing/subscribing, persistence, middleware, and a distributed‑transaction mechanism – with transactional messaging as the core component.

3. Distributed‑transaction solution comparison

Ordinary message + asynchronous reconciliation – cannot guarantee atomicity between business execution and message enqueue.

Local message table – couples the main transaction with message storage, reducing decoupling.

XA two‑phase commit – complex, introduces blocking locks and coordinator‑failure risk.

TCC – ensures consistency but offers little decoupling.

Transactional message: Provides both decoupling and eventual consistency; selected as the optimal pattern.

4. Core process of RocketMQ transactional messages

The transaction centre built on RocketMQ coordinates commit and rollback across services. Using the Discount Purchase as an example, the workflow consists of three phases:

Prepare phase: The business system sends a half‑transaction (prepared) message to the transaction centre. The centre stores the message without publishing it.

Execute main transaction: The business system performs the actual fund purchase (e.g., buying a money‑market fund).

Commit / rollback phase: If the main transaction succeeds, the centre commits the half message, making it visible to downstream consumers; if it fails, a rollback is issued. This two‑phase commit guarantees atomicity even under network glitches or service crashes.

RocketMQ’s built‑in check‑back mechanism detects lost confirmations caused by network jitter. The transaction centre first inspects its internal state, then invokes the checkTransactionState API to query the local transaction result, restores the context, and proceeds accordingly.

5. Ensuring reliable consumption

When a consumer fails to process a message, the broker retries a configurable number of times (default 16). Consumers must implement idempotent handling (e.g., using a unique transaction ID). After exhausting retries, the message is moved to a dead‑letter queue (DLQ); RocketMQ can generate alerts for DLQ entries.

6. Applicable scenarios for transactional messages

Synchronous domain events that require immediate client feedback, such as balance checks before a payment.

Non‑reentrant transactions that need a globally unique transaction identifier to guarantee idempotency, for example order creation where duplicate processing would create multiple orders.

Future Planning

By decoupling upstream and downstream services with RocketMQ and establishing a transaction centre, Boshi Fund now supports distributed transactions across multiple financial use cases, enhancing product‑packaging capabilities. The roadmap includes extending the transaction centre to additional financial scenarios to create greater business value.