How Xianyu’s Underlying Architecture Evolved to Support Growing Business

Image for post
Image for post

By Lu Man, nicknamed Jun’ai at Alibaba.

At the end of last year’s Double 11, Alibaba’s e-commerce platforms had a turnover of 268.4 billion Chinese dollars in just a 24-hour span. That’s the equivalent of more than 2.5 billion US dollars. This in many ways shocked the world. At the peak of the big shopping promotion, the rate of transactions per second reached a peak of 544,000, which was yet another world record breaking number.

Today, as one of Alibaba’s new and growing e-commerce platforms, Xianyu, serving as Alibaba’s take on a second-hand buy-and-sell marketplace, already has 20 million daily active users, with an ever-growing user turnover rate. So, within all of this, you may ask then, how can Alibaba ensure that the transaction process is stable and fast enough to support the kind of business that Xianyu sees on a daily basis.

This article aims to answer this question by covering the evolution of Xianyu’s transaction processes and the underlying architecture that supports it. In short, the evolution of Xianyu’s underlying architecture shows that, while continuing to work hard to ensure performance, the engineers on Alibaba’ s Xianyu team have also continued to improve their research and development efficiency and share the fruits of their research with the greater community.

The Business Characteristics of Xianyu

A potential buyer on the buy-and-sell platform finds an item he or she is interested in and then starts a chat conversation with the seller by clicking an I want it button on the item’s detail page.

If, in the end, the buyer would like to purchase the item after chatting with the seller, the transaction then goes through an order placement process, which is then sequentially followed by the order details and order list processes.

As a part of this, both the platform buyer and seller agree to the terms of the transaction, particularly transaction fulfillment, which involves either the forward transaction track, which involves the payment, shipping, receiving, and rating processes, or the reverse transaction track, which involves the refund and return processes.

Image for post
Image for post

Figure 1: Key scenarios: buyer-and-seller conversation, buying process, and order placement process.

Business operations undertaken by the transaction process include online or in-person transactions, guaranteed transactions, and transactions using the platform’s Xianyu coins. And, there’s also player, recycling, and consignment transactions. Different businesses provide different transaction actions depending on their status on the platform and in the specific transaction procedure. The following example describes a normal customer-to-customer forward transaction process.

Image for post
Image for post

Figure 2: A normal consumer-to-consumer forward transaction process

From the discussion above, we can see that the transaction process on Xianyu is complex, and can be characterized by involving multiple businesses, multiple statuses, and multiple actions.

How Taobao and Xianyu Compare

For similar transaction scenarios, Taobao Mobile is relatively simple, and besides that, Taobao Mobile provides a good solution: Ultronage. Ultronage uses block-based and behavior-based page communication protocols and provides business-based pages, components, and rules. The frontend implements dynamic templates, and the backend orchestrates pages based on business on the platform to achieve dynamic cross-end and cross-component interaction.

Image for post
Image for post

Figure 3: Ultronage for Taobao Mobile

Xianyu involves a complex consumer-to-consumer (C2C) transaction mode, which differs significantly from the business to customer transaction mode of Taobao Mobile. Xianyu has no shopping cart and cannot merge multiple items into a single order. Due to the business characteristics of Xianyu, its transaction process cannot be completed on the same transaction system as Taobao Mobile.

The C2C transaction process of Xianyu has relatively fixed businesses and low requirements for page dynamics. In this context, migrating the frontend and backend to Ultronage is costly and less profitable. In addition, the backend development of Ultronage requires page orchestration, which is not the final research and development model. Therefore, Ultronage was not selected as the technical platform for Xianyu. The transaction process of Xianyu focuses on the following aspects:

  • Stability: To ensure consistency and reduce logic inconsistencies between the server and the client.
  • Certain dynamic capabilities: To process page rendering only on the client and migrate business logic to the cloud.
  • New R&D model: To provide in-depth business at the frontend by implementing page rendering logic on the server and focus on building domains at the backend through cloud integration.

To achieve the preceding goals, the transaction process architecture has gone through three phases:

Image for post
Image for post

Figure 4: Evolution of Xianyu’s transaction process

Figure 5 shows the evolution process of Xianyu’s transaction process architecture.

Image for post
Image for post

Figure 5: Evolution of Xianyu’s transaction process architecture

Phase 1: Decoupling Business

At that time, the servers were divided into three layers: underlying data models, C2X transaction domains of Xianyu, and business solutions. At the backend, underlying data models were used to build C2X, the transaction domain of Xianyu based on different business characteristics and the business logic of Xianyu. Then, business solutions were used to provide business data for different scenarios.

Clients were divided into two layers. The business data parsing layer parsed and integrated backend business data based on different business types and transaction statuses and converted the data into the ViewModel page rendering protocol. In addition, the client implemented block-based pages to extract common business components for direct rendering based on ViewModel.

  • Block-based pages
  • Actions

Phase 2: Server and Client Integration and Gradual Migration to the Cloud

  • Flutter and Fish Redux
  • Transaction action center
  • Business migration to the cloud

At that time, the servers were still divided into three layers: underlying data model, Xianyu C2X transaction domain, and business layer. The business layer contained business solutions and page rendering and parsing. Only the rendering layer was retained on the client.

Phase 3: Cloud Integration

At this time, we chose the unified technology stack Dart, built Function-as-a-Service (FaaS) capabilities, and adopted the cloud-integrated R&D model of Flutter + FaaS (Dart Runtime). Our client personnel were asked to write Python code for the server, but did not need to concern themselves with traditional work, such as server O&M and resizing. Our client personnel performed the original business aggregation and rendering protocol parsing on the server to implement logic normalization, a closed loop encompassing the entire R&D process, and the optimization of resource configurations.

Image for post
Image for post

Figure 6: Cloud-integrated engineering system

In the cloud-integrated R&D model, the server is re-layered. The backend personnel focus on building domains, and the client personnel develop original business solutions and parse the rendering protocol, as shown in the red boxes in Figure 8. In actual development, FaaS and domains overlap due to actual business.

  • Server development: completed domain building.
  • Client development: aggregated multi-domain information, implemented the rendering protocol, and performed UI rendering directly on the client.
Image for post
Image for post

Figure 7: Detailed architecture in the cloud integration phase

We also classify backend operations on the transaction link into rendering operations and interaction operations.

  • The rendering operations provide page rendering data. Figure 9 shows the code structure of the FaaS part. After completing the operation verification, we defined page protocols and aggregated and filled multi-domain data based on business requirements.
Image for post
Image for post

Figure 8: Design of rendering operations

  • A transaction may involve multiple actions. In different businesses, new actions are often required. The actions contained in different order types and different order statuses are dynamically configured by the rendering operations. For example, a common C2C transaction order that is “ordered but not paid” contains actions such as “paying” and “closing the transaction”. The implementation after an action is triggered requires interactions such as verifying business and triggering domain services, which are completely migrated to the FaaS by the client. The Nexus framework of Xianyu uses the Action communication protocol of Logic Engine. For example, assume that a user triggers an action for creating an order, or specifically, triggers the CREATE_ORDER action. After the FaaS calls the domain service for creating an order, a native API is called to trigger corresponding actions on the client to invoke the checkout counter and jump link.
Image for post
Image for post

Figure 9: Design of interaction operations

Summary

This article describes the evolution process of Xianyu’s transaction process and several of our considerations. Different business scenarios need to use different business architectures. During business development, it is common to encounter various problems or bottlenecks. Therefore, selecting reasonable technical solutions by balancing profits and costs based on current business problems and development directions is essential. The cloud-integrated application architecture of Xianyu not only can be used for the transaction process, but also will constantly evolve and expand into new areas.

Original Source:

Follow me to keep abreast with the latest technology news, industry insights, and developer trends.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store