Designing a Scalable E‑Commerce Architecture with SOA, Dubbo, and a Product Query DSL – Haier’s Experience

Author: Liu Zhibin, Chief Architect of Haier E‑Commerce, senior technologist with over 10 years of experience in supply‑chain and e‑commerce, previously architect at McKinsey and Maibaobao.

Source: "Programmer" Magazine.

Most e‑commerce platforms experience rapid growth in traffic and revenue, with peak periods such as Double‑11 and anniversary sales generating traffic and orders many times higher than normal, putting extreme pressure on system architecture. Therefore, platform planning must be both visionary and meticulous to avoid performance bottlenecks, costly re‑architectures, and business impact.

Since 2012 Haier has pursued “three‑isms” – platformization, user personalization, and employee maker‑culture – which created a fertile ground for e‑commerce growth. Haier’s own platform faced the same challenges, and the following shares its architectural experience for handling peak loads.

SOA Architecture on the Shoulders of Giants

As e‑commerce business expands, system complexity grows, requiring decomposition into specialized domains and massive sub‑site splitting to handle traffic. Service‑Oriented Architecture (SOA) provides clear structure, logical organization, and facilitates business optimization and new service development.

By encapsulating services and enforcing strict separation, the platform achieves high scalability. Most scalability work is confined within services, making client‑side impact assessment and refactoring straightforward, reducing effort and implementation time.

Dubbo, an open‑source RPC framework from Alibaba, offers excellent performance under high concurrency. Haier’s SOA is built entirely on Dubbo. Each provider registers with a registry center via a long‑lived connection; the registry maintains a live list of providers. Consumers obtain the provider list from the registry, establish direct long‑lived connections, and invoke services without passing through the registry, avoiding a bottleneck. Load‑balancing, fault‑tolerance, and monitoring (e.g., call counts and latency) are also supported.

Figure 1: Dubbo Service Deployment Diagram

Dubbo delivers high performance, high availability, ease of use, and strong extensibility. All Haier e‑commerce services are built on Dubbo, as shown in the overall SOA diagram below.

Figure 2: Haier E‑Commerce SOA Architecture

Balancing Product Service Challenges

Challenges

High load: Product retrieval dominates front‑end traffic, especially during peak events, demanding high availability, performance, and scalability.

Great product diversity: Different categories have varied attributes, requiring a flexible and generic data model.

Comprehensive search and sorting: Users need fast, multi‑dimensional search (keyword, category, attribute combinations) and intelligent ranking, often driven by big‑data analytics.

Static page generation reduces backend load but sacrifices control for advanced personalization; therefore Haier aims to improve backend performance and scalability to avoid static‑page drawbacks.

Performance and scalability are core metrics; sometimes functionality must be sacrificed to meet them. The goal is a solution that offers both high performance and rich features.

Solution

At the database layer, a fine‑grained relational model stores complex product data, providing universal and extensible product schemas while shielding the client from storage complexity.

Figure 3: Product Service Logical Architecture

The product query engine wraps the complex storage model into a simple logical model where each product attribute maps to a column. On top of this model a concise DSL is provided for client queries, allowing developers to write straightforward search expressions without worrying about underlying storage performance.

Product Query DSL

The DSL syntax resembles SQL WHERE clauses, making it easy for developers to learn. Clients send DSL expressions to the server and receive matching product lists and attribute data.

Figure 4: DSL Working Principle

The DSL also supports Chinese syntax, facilitating business users to compose complex backend queries or define front‑end filter conditions.

Product Query Engine

Figure 5 shows the engine’s core components and data flow. The compiler, built with ANTLR, parses DSL into an abstract syntax tree and performs optimizations. The execution engine walks the tree to match products, while the intelligent ranking engine orders results based on a competitiveness model to maximize conversion. The result builder assembles the requested attributes for the client.

Figure 5: Query Engine Workflow

Product data is cached in memory at service startup and refreshed via MQ subscriptions when changes occur.

Product Service Deployment

Services are deployed in separate clusters; web‑facing clusters rarely hit the database, so even during massive traffic spikes the database remains unburdened. Adding more web or service nodes suffices to meet peak demand.

Results

Performance: Peak 260 million requests per day, average 60 ms per request; further gains possible after compiler and engine optimizations.

Scalability: Near‑linear scaling under appropriate conditions; no additional designs needed for high traffic.

Universality: The model is not limited by e‑commerce performance needs and can be reused for internal systems like PDM.

Extensibility: Logical model shields underlying storage, minimizing effort and impact of schema changes.

The query‑engine‑centric product service demonstrates that universality, extensibility, and scalability can be achieved simultaneously in a large‑scale e‑commerce platform.

Copyright statement: Content sourced from the internet; rights belong to the original author. We credit the author and source unless unable to verify. Please inform us of any infringement.