Designing Distributed Transaction Architecture and Ensuring Data Consistency in a Flow Recharge System

In distributed transaction scenarios, the design principle is to treat a large transaction as a combination of small atomic transactions plus asynchronous messaging, thereby avoiding true distributed transactions and achieving eventual consistency through compensation flows.

What is a transaction? A transaction is a logical unit of work consisting of multiple SQL statements and follows the ACID properties: Atomicity, Consistency, Isolation, and Durability.

Typical scenario – bank transfer: When transferring money, the system must ensure that the total amount remains consistent before and after the transaction, and the operation must be idempotent.

E‑commerce scenario – flow recharge: The flow‑recharge capability center follows a process of selecting a product, creating an order, choosing a payment method, and crediting the flow in near real‑time. Although it lacks physical logistics, the workflow is similar to traditional e‑commerce with inventory and discounts.

Distributed vs. local transactions: Both aim to guarantee data correctness (ACID). Local (rigid) transactions execute within a single physical node, while distributed (flexible) transactions span multiple nodes, making traditional locking ineffective and requiring eventual consistency mechanisms.

Alibaba’s flexible transaction implementations include four patterns: two‑phase commit, compensation, asynchronous assurance, and maximum‑effort notification.

Micro‑service decomposition of the flow‑recharge system (via Dubbo):

Product service

Order service

Inventory service

Payment service

Direct‑charge service

Message service

Other auxiliary services

Scenario 1 – Inventory and order consistency: Uses compensation + maximum‑effort notification. Stock is reduced first; if order creation fails, stock is rolled back, and a delayed message retries the rollback if needed.

Scenario 2 – Order, payment, and recharge consistency: Uses asynchronous assurance due to long, cross‑region workflow. After order creation, payment is processed, and upon successful recharge, the order status is updated; failures trigger refunds or retry mechanisms with timed retries.

Scenario 3 – Post‑recharge notification: Uses maximum‑effort notification to send app or SMS messages; failures are retried via scheduled tasks.

Scenario 4 – Reconciliation and settlement: Daily T+1 reconciliation compares payment records, order records, and CRM recharge records; settled data then flows into financial settlement processes.

Architecture design: The system follows a micro‑service architecture with independent services, stateless request handling, and vertically/horizontally split storage (MySQL, Redis, Codis, Mycat, Snowflake ID). Scaling is achieved by adding stateless compute nodes and horizontally partitioning data. Performance, capacity, and storage strategies are detailed, supported by diagrams.

Disclaimer: The article includes a promotional link for a book giveaway and notes about limited comment capacity.