vivo Transaction Platform: Architecture Design and Key Technical Solutions

This article introduces the design philosophy and key technical solutions of vivo's e-commerce transaction platform, along with insights and challenges from practical implementation.

Background: After seven years of iteration, vivo's official mall evolved from a monolithic architecture to microservices. The team undertook the construction of an O2O mall, a gift middleware, and a new online-to-offline delivery service. To save R&D and operational costs while avoiding redundant development, they adopted a platform-based approach to build underlying systems including transaction, product, inventory, and marketing platforms.

Architecture Goals: Beyond high concurrency, performance, and availability, the platform aims for low cost (through reusable models and services) and high scalability (simple architecture with low coupling).

Key Technical Solutions:

1. Multi-Tenant Design: Using MySQL with ShardingSphere as the sharding middleware, userId serves as the shard key to ensure orders from the same user are stored in the same database. Tenant code maps to database/table allocation parameters. The article explains the formula for calculating database and table indices to avoid data skew when database and table counts share common factors.

2. Global Unique ID: Referencing Snowflake algorithm to generate globally unique order numbers, with database/table numbers encoded in two 5-bit fields within the order number.

3. Full Database Search: Redundant storage of order data in Elasticsearch for flexible querying across all orders.

4. State Machine Design: Introduced order state machines allowing each tenant to configure multiple differentiated order flows. Configuration includes initial order status and allowed operations for each status. The state machine formula is: StateMachine(E, S → A, S'), representing event E triggering action A to transition from state S to S'.

5. Generic Operation Triggers: A universal delayed task solution using configuration for trigger registration time, execution time (using JsonPath expressions), registration conditions (QLExpress), and execution conditions.

6. Distributed Transactions:

Strong Consistency: Using Seata AT mode for scenarios like order creation/cancellation affecting inventory and coupons.

Eventual Consistency: Using local message table pattern for scenarios like payment notification to shipping system and points reward distribution.

7. High Availability and Security: Circuit breaking (Hystrix), rate limiting, concurrent locks (database row-level locks), idempotency, network isolation, and comprehensive monitoring/alerting.

Conclusion: The transaction platform has been online for over a year, serving three business tenants with stable operation. The team emphasizes choosing appropriate solutions based on actual team and system conditions rather than pursuing cutting-edge technologies.