Design and Implementation of a Scalable Transaction Platform for Vivo Global Mall

The Vivo official mall evolved from a monolithic system to a micro‑service architecture over seven years, prompting the need for a unified transaction, product, and inventory platform to support O2O commerce, gift services, and offline delivery.

The platform’s architectural goals include high concurrency, high performance, high availability, low cost, and high extensibility, achieved through a simple, loosely‑coupled design that supports horizontal scaling.

System architecture consists of an overall e‑commerce platform with a dedicated transaction subsystem, illustrated by the following diagrams:

Data is stored in MySQL with ShardingSphere handling database‑table sharding. The tenant identifier (tenantCode) is used as a routing key, and the user ID (userId) serves as the shard key, ensuring that a user’s orders reside in the same database.

Mapping rules (tenantCode → {dbCount, tableCount, startDb, startTable}) enable flexible resource allocation per tenant. Example mappings demonstrate reuse of existing databases for low‑traffic tenants and allocation of new databases for high‑traffic tenants.

Order‑ID generation adopts a Snowflake‑style algorithm that embeds the database and table indices within a globally unique 64‑bit ID, allowing the system to retrieve routing information even when the user ID is unavailable.

The order workflow is managed by a configurable state machine. Each tenant defines initial states and permissible actions in JSON, which are persisted in a configuration center. The following Java model illustrates the configuration structure:

/**
 * Order flow configuration
 */
@Data
public class OrderFlowConfig implements Serializable {
    /**
     * Initial order status code
     */
    private String initStatus;
    /**
     * Map
>
     */
    private Map
> operations;
}

Common operation triggers address delayed business requirements (e.g., auto‑close unpaid orders). Triggers are defined with registration time, execution time (via JsonPath), registration condition, execution condition, and the action with parameters, all expressed using QLExpress.

Distributed transaction challenges are solved by distinguishing strong‑consistency and eventual‑consistency scenarios. Strong consistency (e.g., order creation with inventory deduction) uses Seata’s AT mode, while eventual consistency (e.g., post‑payment notifications) relies on a local message table with compensating retries.

High‑availability and security measures include Hystrix circuit breaking, rate limiting based on performance testing, row‑level locking for concurrency control, idempotent APIs, network isolation with whitelist and encryption, and comprehensive monitoring and alerting.

Additional considerations cover the decision against full domain‑driven design due to team structure, handling peak‑load bottlenecks with degradation strategies (e.g., async writes, cache fallback), and future plans to decouple the fulfillment module.

In summary, the transaction platform balances pragmatic engineering with selective adoption of advanced techniques, has been stable for over a year serving multiple business lines, and continues to evolve to meet growing demands.