How RocketMQ Transaction Messages Decouple Financial Services

Industry Background

Fund companies operate two main lines: investment‑research (investment management and industry research) and market‑line (fund sales and customer service). With the rise of internet channels, online sales have become a major avenue, bringing a large and heterogeneous customer base that requires guided risk education.

RocketMQ in the Companion System

Companion Scenarios

The firm built a multi‑layer companion system that delivers warm, end‑to‑end investment experiences before, during, and after purchase, involving research, compliance, operations, big‑data and other subsystems.

Synchronous calls among these subsystems would create high coupling and hinder scalability.

Decoupling Heterogeneous Systems with RocketMQ

RocketMQ provides reliable messaging and a publish‑subscribe mechanism, moving collaboration from file‑ or email‑based processes to fully online, automated workflows, greatly improving companion‑output efficiency.

Messages are classified with Topics (primary classification) and Tags (secondary classification) to enable filtering and indexing.

Topic and Tag Best Practices

Operations system subscribes to operational messages (TagA).

Customer‑service system subscribes to service messages (TagB).

Companion orchestration system subscribes to orchestration messages (TagC).

Compliance system subscribes to TagA and TagC for audit.

Data‑center listens to all tags.

Financial Application of RocketMQ Transaction Messages

Discount‑Purchase Scenario

Two implementation patterns for a fund‑app discount purchase:

Separate wallet recharge and fund purchase (two steps, higher churn).

Bundle the two steps into a single transactional operation, simplifying the user flow.

Domain‑Event Theory Model

Domain events represent a business step that triggers subsequent operations (e.g., login event, fund‑purchase event). In a micro‑service architecture, events enable eventual consistency and decoupling because services do not need strong data synchronisation.

Two cases:

Events occurring within the same micro‑service – can be handled directly or via an internal event bus.

Cross‑micro‑service events – require a coordinator to drive a global transaction, involving event construction, publishing/subscribing, persistence, MQ and distributed‑transaction mechanisms. Transactional messages in MQ are the core component for this solution.

Distributed‑Transaction Solution Comparison

The fund business needs to balance transaction consistency with service decoupling. Evaluated solutions:

Ordinary message + asynchronous reconciliation : high decoupling, moderate consistency; relies on delayed compensation.

Local message table : higher consistency but couples the main transaction with message storage.

XA (2PC) : strong consistency, no decoupling; introduces blocking, lock contention and coordinator‑failure risk.

TCC : high consistency, no decoupling; incurs heavy business‑logic intrusion.

Transaction messages (RocketMQ) : provides both high decoupling and high consistency; chosen as the optimal solution.

Core Flow of RocketMQ Transaction Messages

Building a transaction centre on RocketMQ coordinates the two‑phase commit and possible rollback.

Using the discount‑purchase example:

Prepare phase : the business system sends a half‑message to the transaction centre; the message is invisible to consumers.

Business execution : the main transaction (e.g., purchase of a money‑market fund) is performed.

Commit / Rollback phase : if the main transaction succeeds, the centre commits the message; otherwise it rolls back. This guarantees final consistency even if failures occur before or after the enqueue operation.

Network glitches may cause loss of the second‑phase confirmation. RocketMQ’s back‑check mechanism allows the transaction centre to query the local transaction result and recover the transaction context.

Back‑Check Mechanism Flow

The centre first checks its internal state, then calls the back‑check interface to retrieve the local transaction outcome, restores the context, and proceeds with normal processing.

Ensuring Consumption of Transaction Messages

When a consumer fails, the broker retries a configurable number of times. Consumers must implement idempotent processing. After exhausting retries, the message is moved to a dead‑letter queue (DLQ) where RocketMQ can trigger alerts.

Retry strategy

Idempotence

Dead‑letter queue

Alerting

Business intervention if needed

Applicable Scenarios for Transaction Messages

Synchronous Domain Events

When a domain event has a high failure probability and the client needs an immediate response (e.g., payment balance check), it cannot be placed in an asynchronous flow.

Non‑Reentrant Transactions

If a unique transaction ID cannot be guaranteed, idempotency fails, leading to duplicate orders. Transaction messages provide a unique ID and guarantee idempotent processing.

Outlook

Supporting transaction messages in a distributed message queue is a cornerstone of digital transformation. The RocketMQ‑based companion system has decoupled upstream and downstream services, improved operational efficiency, and built a coordination platform for financial scenarios. Future work will extend the transaction centre to additional financial use cases, creating greater business value.

http://www.javaedge.cn/